diff --git a/docs/staging/new-packages.md b/docs/staging/new-packages.md new file mode 100644 index 00000000..3fd48ee9 --- /dev/null +++ b/docs/staging/new-packages.md @@ -0,0 +1,202 @@ +(new-packages)= +# New packages + +```{note} +This content comes [from the wiki](https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages) +It has not yet been reviewed for currency or accuracy. +Last updated: 2025 +``` + +## Criteria + +In order for a piece of software to be included in Ubuntu, it must meet the +[Ubuntu License Policy](https://help.ubuntu.com/community/License). + +## Requesting a new package for Ubuntu + +Packages that have recently been added to Debian unstable will be automatically +synced into Ubuntu prior to the +[Debian Import Freeze (DIF)](https://wiki.ubuntu.com/DebianImportFreeze). +After the Debian Import Freeze, you will have to +[file a bug](https://launchpad.net/ubuntu/+filebug/?no-redirect) with the +summary field "Please sync `` from debian ``" where +`` is the package you would like to see. Find the date for Debian +Import Freeze on +[the release schedule page](https://wiki.ubuntu.com/ReleaseSchedule). + +To get a package into Ubuntu, please +[file a bug in Launchpad](https://bugs.launchpad.net/ubuntu/+filebug?no-redirect&field.tag=needs-packaging) +and make sure it has the tag [`needs-packaging`](https://lists.ubuntu.com/archives/ubuntu-motu/2007-March/001471.html). +Please mention where to get the source for it and which license it is under. An +example request [is shown here](https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages/ExamplePackageRequest). +Make sure you check which [packages have already been requested](https://launchpad.net/ubuntu/+bugs?field.tag=needs-packaging). + +Because we want Free Software to reach as many people as possible and do not +want to have too much duplication of packaging effort, it is useful for packages +that meet the requirements of the +[Debian Free Software Guidelines](http://www.debian.org/social_contract#guidelines) +to be requested within Debian's +[Work-Needing and Prospective Packages](http://www.debian.org/devel/wnpp/) +(WNPP) process by filing a Request for Package (RFP) bug on the WNPP package in +Debian's bugtracker. + +If you file a `needs-packaging` bug, please link it to the Debian WNPP bug as +well. + +## Packaging it yourself + +You can follow the [Packaging Guide directives](http://packaging.ubuntu.com/html/). + +To get a screenshot included for software-center, please use http://screenshots.debian.net/upload + +### NEW packages through Debian + +Ubuntu regularly incorporates source packages from Debian, so it is encouraged +to upload a package to Debian first to automatically have it in Ubuntu in due +time. In addition to that, your package will reach a much broader audience if +it is in Debian and all of its derivatives. + +In order to have faster reviews, several teams have been set up to manage a +given subset of packages. Some of them are: + +* [Debian GNOME Team](http://wiki.debian.org/Teams/DebianGnome) +* [Debian KDE Team](http://pkg-kde.alioth.debian.org/) +* [Debian XFCE Group](http://wiki.debian.org/Teams/DebianXfceGroup) +* [Debian Games Team](http://wiki.debian.org/Games/Team) +* [Debian Multimedia](http://wiki.debian.org/DebianMultimedia) +* [Debian Perl Group](http://wiki.debian.org/Teams/DebianPerlGroup) +* [Debian Python Modules Team](http://wiki.debian.org/Teams/PythonModulesTeam) +* [Debian Python Applications Packaging Team](http://wiki.debian.org/Teams/PythonAppsPackagingTeam) +* [Debian CLI Applications Team](http://wiki.debian.org/Teams/DebianCliAppsTeam) +* [Debian Mozilla Extension Team](http://wiki.debian.org/Teams/DebianMozExtTeam) +* [Debian X Team](http://pkg-xorg.alioth.debian.org/) + +More teams [can be found here](http://wiki.debian.org/Teams). If there is no +team available that takes care of the group of packages you are interested in, +contact the Debian mentors (see "Further Reading" below). + +Ubuntu does virtually all package maintenance in teams. If your package is +related to any of the existing teams within Debian, work with that team to get +the package uploaded to Debian. If there is no team already, you should consider +starting a new team within Debian (e.g. at Alioth) for any package that is +likely to have a significant number of bugs or other maintenance overheads +(like architecture-specific issues). + +Additionally there are roughly an order of magnitude more Debian Developers +than Ubuntu developers. It is quite difficult to get a new package into Ubuntu +due to the sheer volume of requests compared to the available resources for +reviews. In many cases, people have an easier time getting their package into +Ubuntu via Debian than directly. + +If you choose to do this, file an [Intent to Package (ITP)](http://www.debian.org/devel/wnpp/being_packaged) +bug on the WNPP package in Debian to let others know that you're working on it +(`reportbug -B debian wnpp` should do the right thing), then go through the +[Debian Mentors](http://mentors.debian.net/cgi-bin/welcome) to get the package +uploaded. A number of Ubuntu Developers are also Debian Maintainers or Debian +Developers, so they may be able to help you navigate Ubuntu/Debian interactions. + +```{admonition} Some good tips +:class: tip +* [Follow the procedures](http://www.debian.org/doc/manuals/developers-reference/pkgs.html#newpackage) + to get a [new package into Debian](http://ftp-master.debian.org/new.html). +* Subscribe to bugs of the package once it is accepted. +``` + +### Going through MOTU + +Submitting new packages through Debian is the preferred path. But, if your +package is Ubuntu-specific or can't go into Debian for some other reason, you +can submit it directly to MOTU. There are a limited number of available +reviewers, so you may encounter delays here. + +New packages require extra scrutiny and go through a special review process, +before they get uploaded and get a final review by the [Archive Admins](http://launchpad.net/~ubuntu-archive). +More information on the review process, including the criteria that will be +applied, can be found on the [Code Reviewers page](https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#NewPackage). +Developers are encouraged to examine their own packages using these guidelines +prior to submitting them for review. + +To receive higher quality bug reports write an +[apport hook](https://wiki.ubuntu.com/Apport#Per-package%20Apport%20Hooks) for your package. + +The [MOTU](https://wiki.ubuntu.com/MOTU) team approval policy for new packages: + +* New MOTU contributors (who are not [members of the MOTU team](https://launchpad.net/~motu) + yet), need to get their packages reviewed and signed off by two + [MOTUs (core-devs are included in this)](https://launchpad.net/~motu/+members) + to get them uploaded to Ubuntu. + +* MOTUs can upload new packages directly to the archive. However they are + greatly encouraged to have a new package reviewed prior to uploading. + (cf. [MOTU/Council/Meetings/2007-02-23](https://wiki.ubuntu.com/MOTU/Council/Meetings/2007-02-23)) + +The MOTU team uses the following workflow: + +* Join the `#ubuntu-devel` channel on `irc.libera.chat` and talk with the MOTU. + It's good to do this early on, to get advice on how to package (avoid common + mistakes), to find out if your package is likely to be accepted (before you + invest a lot of work in packaging it), and to find mentors willing to sponsor + your package or to point you in the right direction. + +* When you start to work on a new package, assign the `needs-packaging` bug to + yourself and set it to "In Progress" (if there is no `needs-packaging` bug, + [file one](http://bugs.launchpad.net/ubuntu/+filebug?no-redirect&field.tag#needs-packaging)). + +* Once you have an initial package, follow the + [new packaging instructions](http://packaging.ubuntu.com/html/packaging-new-software.html#next-steps) + to upload it to your PPA or a Launchpad branch, then add a link to the package + in the description of the bug. Requests for changes or other communication + about your package will be made as comments on your bug. Subscribing + `ubuntu-sponsors` to sponsorship requests is generally advised, as it makes + the request appear on the list that people look at. + +* Once the approved package is uploaded, the uploading MOTU will set the bug + status to "Fix Committed". + +* When the package clears the NEW queue it will automatically be set to "Fix + Released" (`debian/changelog` must close the `needs-packaging` bug). This is + done with a bullet point that follows the format: + + * `Initial release (LP: #242910)` + + where "LP" refers to "Launchpad". See the Packaging Guide for + [more information on changelogs](https://wiki.ubuntu.com/PackagingGuide/Howtos/PackagingFromScratchHelloChangelog). + +* Even if you don't run Debian as your primary OS, most packaging can be tested + perfectly well in a chroot, or failing that in a VM (and most packages will + work fine without any changes anyway). + (→ [Using Development Releases](https://wiki.ubuntu.com/UsingDevelopmentReleases)) + +* `#debian-ubuntu` on OFTC and the + [debian-derivatives mailing list](http://lists.debian.org/debian-derivatives/) + are good places for Ubuntu developers to ask their questions. + + +### Deadline + +[Feature Freeze](https://wiki.ubuntu.com/FeatureFreeze) is the latest approval +date, it is recommended to get things done in a couple of weeks earlier, as +getting approval may take some time. + + +## Further reading + +* Always check if there is an {term}`Intent to Package (ITP) ` + [bug filed against the WNPP package](http://bugs.debian.org/wnpp) in Debian. + That means, somebody is already working on packaging the software for Debian. + Join forces with them rather than reinventing the wheel. + +* [mentors.debian.net](http://mentors.debian.net/), a website where people + interested in getting their packages into Debian can upload their packages. + You need to [browse the directories](http://mentors.debian.net/debian/pool/) + to find packages. [Contributing To Debian](https://wiki.ubuntu.com/ContributingToDebian) + has additional information on getting your work into Debian. + (→ [Debian Mentors FAQ](http://wiki.debian.org/DebianMentorsFaq)) + +* [Debian's SCM](https://salsa.debian.org/) -- it's possible that a package has + been worked on for Debian but has a status of UNRELEASED. Check the + appropriate directories that begin with "pkg" that your package may fall + under. For example, game packages would be under "pkg-games". + [The Debian Package Tracking System](http://packages.qa.debian.org/common/index.html) + will help you find the specific branch where the package is being maintained. + diff --git a/docs/staging/package-archive.md b/docs/staging/package-archive.md new file mode 100644 index 00000000..1ed854ea --- /dev/null +++ b/docs/staging/package-archive.md @@ -0,0 +1,381 @@ +(package-archive)= +# The Package Archive + +```{note} +This content comes [from the wiki](https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive) +It has not yet been reviewed for currency or accuracy. +``` + +All current official Ubuntu packages are stored in the master archive, which is +widely {ref}`mirrored `. +A search interface is available at [http://packages.ubuntu.com](http://packages.ubuntu.com). +Old versions can be retrieved from [Launchpad](http://launchpad.net/ubuntu). + +It is administered by the [archive administration team](http://launchpad.net/~ubuntu-archive). + +(Uploading)= +## Uploading + +If you are not yet an official Ubuntu developer, you can arrange for your +package to be uploaded via the {ref}`sponsorship-process`. + +Packages are [uploaded via FTP](ftp://upload.ubuntu.com/) using `dput` or `dupload`. + +Notes for preparing your upload: + +* Make source-only uploads, i.e. use "`dpkg-buildpackage -S`" +* If you need to include the {term}`orig tarball` as well, use parameters `-S -sa` + +When your upload is processed (typically within a matter of minutes), you will +receive an email with the result of your upload, whether it succeeds or fails, +**unless** you use an unregistered email address. The system will only send mail +to an address which belongs to a launchpad account which is a member of the +relevant team for uploading. E.g. [`motu`](http://launchpad.net/~motu) for +universe and [`ubuntu-core-dev`](http://launchpad.net/~ubuntu-core-dev) for main. + +Your upload must be signed by a GPG key registered in Launchpad. If the +signature cannot be traced to a member of the appropriate team, then the upload +will be **silently rejected**. + +To add a new package to Ubuntu, simply upload it as usual. Any new packages +uploaded are [put in a queue](https://launchpad.net/ubuntu/questing/+queue) to +be checked by the administrators before being included. + +[Ubuntu Development/Uploading](https://wiki.ubuntu.com/UbuntuDevelopment/Uploading) +has much more information about the topic. + +(autobuilding-and-publishing)= +## Autobuilding and publishing + +Once an upload has been accepted, it takes some time to be +[built](https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Autobuilders) +and published in the archive. For simple packages, this is usually on the order +of an hour, but varies depending on release activity (uploads may be temporarily +suspended), the time needed to build the package (including other packages in +the build queue), and other factors. + +After a package has been built, the next publisher run that starts at 3 and 33 +minutes past each hour will process it, usually finishing towards the end of +that half-hour; at the end of that process it will be visible in the public +archive. + +(notification-of-changes)= +## Notification of changes + +Notifications of uploads are sent to a mailing list. A different list is used for each Ubuntu release: + + * [[http://lists.ubuntu.com/mailman/listinfo/hardy-changes/|8.04 (hardy)]] + * [[http://lists.ubuntu.com/mailman/listinfo/lucid-changes|10.04 (lucid)]] + * [[http://lists.ubuntu.com/mailman/listinfo/natty-changes|11.04 (natty)]] + * [[http://lists.ubuntu.com/mailman/listinfo/oneiric-changes|11.10 (oneiric)]] + * [[http://lists.ubuntu.com/mailman/listinfo/precise-changes|12.04 (precise)]] + * [[http://lists.ubuntu.com/mailman/listinfo/quantal-changes|12.10 (quantal)]] + +```{admonition} Question +:class: important +Do we, in principle, want to keep this list? If so, we should consider trying +to create it in a way that makes it better maintainable (otherwise it will get +this out of date again). +``` + +Changelogs for all packages are available at +http://changelogs.ubuntu.com/changelogs/ (this is the source used by +`update-manager` and Synaptic). + +(syncing-and-merging)= +## Syncing and merging + +(See the [Release Process / Merge Process rationale](https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess#MergeProcess_rationale) + +Most packages in Ubuntu originate elsewhere, including Debian and related +package repositories. + +A **sync** copies a source package verbatim from an external repository into +Ubuntu, overwriting any package of the same name. This is used when a newer +version of it is available, and should be included in Ubuntu, and happens +automatically during some phases of the release cycle. To request a sync, +follow the [Sync Request Process](https://wiki.ubuntu.com/SyncRequestProcess). + +A **merge** is a three-way merge of a package which originated in an external +repository. This is used when there is a newer version available from the +external repository, but the package has also been modified (branched) in +Ubuntu. [Merge-o-Matic](http://merges.ubuntu.com) assists with this work, and +[the Merging page](https://wiki.ubuntu.com/UbuntuDevelopment/Merging) explains +how and when to merge. Packages which are +[maintained in Bazaar](https://wiki.ubuntu.com/UbuntuDevelopment/#Bazaar) can +and should be merged using Bazaar itself. + +The "Last Uploader" column in the Merge-o-Matic output is the default assignee +for the merge, following the "touched-it-last" maintenance principle. However, +you can and often should grab other people's merges if they don't have time or +you feel you can do a better job. It's polite and often a good idea (though not +mandatory) to contact the other person first to make sure you aren't +duplicating work. + +Backports work similarly to syncs, but have somewhat different requirements. +To request a backport, follow the +[Ubuntu Backports](https://wiki.ubuntu.com/UbuntuBackports) process. + +(package-archive-consistency)= +## Consistency + +The archive is periodically checked for various inconsistencies, such as +incorrect dependency relationships between packages. + +* https://ubuntu-archive-team.ubuntu.com/proposed-migration/questing_uninst.txt + -- packages which are uninstallable due to unsatisfiable dependencies. +* [Ubuntu Development/NBS](https://wiki.ubuntu.com/UbuntuDevelopment/NBS) - + binary packages that are no longer built by any source package. + These packages are not automatically removed from the archive, since + generally they still have reverse dependencies (packages depending on them). + +(package-archive-freezes)= +## Freezes + +Freezes are restrictions on which changes can be uploaded in order to try and +stabilize Ubuntu for release. There are various different freezes that happen +at different times in the cycle, and they are of different types, affect +different packages, and have different procedures for uploading during them, +so understanding them all can be difficult. + +You can see which freezes happen and when on the +[Release Schedule](https://wiki.ubuntu.com/ReleaseSchedule), and each is linked +to a page about that particular freeze, so that is a great place to go for the +information. This page will provide a bit more explanation about the types of +freezes and how to handle them. + +Freezes are generally also announced on +[`ubuntu-devel-announce`](http://lists.ubuntu.com/ubuntu-devel-announce), so +subscribing to that can keep you up-to-date. However, there aren't reminders +about upcoming freezes posted to that list, so keep on top of which freezes are +upcoming will help you to meet the deadlines in your work. + +### Uploading restrictions + +There are two ways that freezes are enforced, which are known as "soft" and +"hard" freezes. Knowing whether a particular freeze is soft or hard is +important, as it will allow you to know what effect uploading will have, and +who needs to be aware of changes that you make for them to be included. + +#### Soft freezes + +Soft freezes have no mechanism in the archive software to enforce them, they +just rely on each developer to ensure that they only upload appropriate changes. + +For instance, [Feature Freeze](https://wiki.ubuntu.com/FeatureFreeze) is a soft +freeze, as you can still upload as before, you are just required to seek +exceptions for new features. + +Most importantly, freezes for the alpha releases of Ubuntu are soft freezes. +This means that nothing will prevent your changes from entering the archive, so +you must ensure that they don't interfere with the process of releasing the +alpha. Convention for milestone stabilization is to upload to `-proposed`, +during this freeze interval. See the section on milestone freezes later for +more information on what this means. + +#### Hard freezes + +In contrast to soft freezes, hard freezes flick a switch in the archive +software such that all uploads are not immediately accepted, they instead end +up in the UNAPPROVED Queue. Packages remain in this queue until they are +explicitly accepted by an Archive Administrator. + +This means that your changes can be reviewed before they are accepted, so that +extra review can be done, and it is not left to your discretion to enforce the +rules of the freeze. + +While this could mean that you could upload with less care, it is not wise to, +as those who can review are generally very busy at this time already, and extra +work at these crucial periods is not appreciated. It is generally a good idea to +ensure that someone on the release team knows that you will be making an upload +to fix the particular issue before you do so (fixing a release critical bug is +generally permission enough). + +(package-archive-components)= +## Managing components + +Ubuntu packages are classified into components according to +[maintenance and licensing criteria](http://www.ubuntu.com/ubuntu/components), +a process which is described in {ref}`seed-management`. + +Packages sometimes move from one component to another, according to policy or +licensing changes, as managed by the archive administrators. Special +consideration is necessary when packages move into `main` or `restricted`, as +this implies a commitment of ongoing maintenance. Such changes must follow the +[Main Inclusion Process](https://wiki.ubuntu.com/MainInclusionProcess). + +(package-archive-autobuilders)= +## Autobuilders + +Ubuntu source packages are automatically built for a variety of platforms by +Launchpad, which provides [build status information](https://launchpad.net/ubuntu/+builds). +Build log files are available from Launchpad as well, by +[searching for the package](https://launchpad.net/ubuntu/) and selecting a version. + +Some supplementary information about the build infrastructure is available on +[Build Daemons](https://wiki.ubuntu.com/BuildDaemons). + +(Removals)= +## Removing Packages + +Packages which are removed from Debian are semi-automatically removed from +Ubuntu universe on a regular basis by the administrators. However, packages are +not removed from Ubuntu {term}`Main` without explicit request, nor are packages +which originated elsewhere. To request removal of such a package, file a bug +against the package. + +The bug must have the following elements: + +* Which release to remove it from (e.g., `hardy`) + +* Whether to remove both the source package and all binary packages + +* A rationale for why they should be removed + +* Confirmation that the binary packages have no `rdepends` (no other package + depends on them) + + * There is `checkrdepends` in `ubuntu-archive-tools`, but it needs a mirror + to work with. + + * There is `reverse-depends` and `reverse-depends -b` (build depends) in + `ubuntu-dev-tools`, but it can return false positives for alternative + dependencies. + +If you are not an [Ubuntu Developer](https://wiki.ubuntu.com/UbuntuDevelopers) +use the following {ref}`sponsorship-process`. If you are an Ubuntu Developer, +then subscribe the `ubuntu-archive` team to the bugs. If you need help deciding +whether a package ought to be removed, please discuss on the `ubuntu-devel` +mailing list rather than asking the archive administrators. + +Refer to `https://launchpad.net/ubuntu/+source/` for the reason +of the removal of a specific package. + +(package-archive-architectures)= +## Architectures + +Packages are typically built for each of several architectures. For example, +the `hello` package is built on {term}`i386`, {term}`amd64`, etc. These are +divided into categories according to their level of use and official support by +the project. + +### Official architectures + +These are officially supported and maintained by the Ubuntu project. +{term}`Canonical` provides server resources to build, store and distribute +packages and installation media for them, and the core development team is +responsible for their upkeep. + +Build failures on these architectures are considered serious bugs. Each official +Ubuntu release and update includes appropriate support for these architectures. +There may or may not be a team which is specifically responsible for +architecture-specific issues. The kernel team builds and tests the Ubuntu +kernel on these architectures: + +* `amd64` + +* `armhf` + +* `i386` + +### Unofficial architectures + +These are maintained on a best-effort basis by interested volunteers in the +Ubuntu community. Each architecture has a corresponding community team formed +of the developers who support it. {term}`Canonical` provides server resources +to build, store and distribute packages and installation media for ports, +however, the porting teams are responsible for their operation and maintenance, +including the kernel, toolchain and build infrastructure. + +Build failures are not considered a serious issue by the core team. Ports may +issue new releases or updates out of sync with official Ubuntu releases. + +* `arm64` + +* `armel` (official from Ubuntu 9.10 to Ubuntu 11.10; [discontinued as of Ubuntu 13.04](https://lists.ubuntu.com/archives/ubuntu-devel/2012-November/036106.html)) + +* `hppa` ([HPPAPortStatus](https://wiki.ubuntu.com/HPPAPortStatus), https://launchpad.net/~ubuntu-hppa) + ([discontinued as of Ubuntu 9.10](https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-May/000571.html)) + +* `ia64` ([IA64PortStatus](https://wiki.ubuntu.com/IA64PortStatus), https://launchpad.net/~ubuntu-ia64) + ([discontinued as of Ubuntu 10.10](https://lists.ubuntu.com/archives/technical-board/2010-August/000441.html)) + +* `lpia` ([discontinued as of Ubuntu 10.04](https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-November/000643.html)) + +* `powerpc` (https://launchpad.net/~ubuntu-powerpc) + ([official up to Ubuntu 6.10](https://lists.ubuntu.com/archives/ubuntu-announce/2007-February/000098.html)) + +* `ppc64el` + +* `sparc` ([official up to Ubuntu 7.10](https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-March/000400.html); + [discontinued as of Ubuntu 10.10](https://lists.ubuntu.com/archives/technical-board/2010-August/000441.html)) + +### Primary architectures + +These are provided on archive.ubuntu.com, and [are widely mirrored](https://launchpad.net/ubuntu/+archivemirrors). + +* `amd64` + +* `i386` + +### Ports + +These are provided only on `ports.ubuntu.com`, and are not generally available +on the mirror network. This decision is made on the basis of levels of use; +mirrors on the mirror network only have so much space available, and so we only +designate as primary those architectures which have very high download rates. + +* `arm64` (from Ubuntu 13.10) + +* `armel` (from Ubuntu 9.04; [discontinued as of Ubuntu 13.04](https://lists.ubuntu.com/archives/ubuntu-devel/2012-November/036106.html)) + +* `armhf` (from Ubuntu 12.04) + +* `hppa` ([HPPAPortStatus](https://wiki.ubuntu.com/HPPAPortStatus), + https://launchpad.net/~ubuntu-hppa) + ([discontinued as of Ubuntu 9.10](https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-May/000571.html)) + +* `ia64` ([IA64PortStatus](https://wiki.ubuntu.com/IA64PortStatus), + https://launchpad.net/~ubuntu-ia64) + ([discontinued as of Ubuntu 10.10](https://lists.ubuntu.com/archives/technical-board/2010-August/000441.html)) + +* `lpia` ([discontinued as of Ubuntu 10.04](https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-November/000643.html)) + +* `powerpc` (https://launchpad.net/~ubuntu-powerpc) + +* `ppc64el` (from Ubuntu 14.04) + +* `s390x` (from Ubuntu 16.04) + +* `sparc` ([discontinued as of Ubuntu 10.10](https://lists.ubuntu.com/archives/technical-board/2010-August/000441.html)) + +The ports system [was announced here](https://lists.ubuntu.com/archives/ubuntu-announce/2005-October/000040.html) + +### Summary as of Ubuntu 14.04 + +| | Official | Unofficial | +| ------- | -------- | ---------- | +| Primary | amd64, i386 | | +| Ports | armhf | arm64, powerpc, ppc64el | + +(package-archive-installation-media)= +## Installation media + +Installation media (for CDs, DVDs, USB drives, etc.) are built from the package +archive, and published on different hosts as follows. + +### `releases.ubuntu.com` + +[releases.ubuntu.com](http://releases.ubuntu.com/) hosts the most frequently +downloaded images. It is [widely mirrored](https://launchpad.net/ubuntu/+cdmirrors). +All images here are officially supported by the Ubuntu project. + +### `cdimage.ubuntu.com` + +[cdimage.ubuntu.com](http://cdimage.ubuntu.com/) hosts less frequently +downloaded images. It is not widely mirrored due to its very large size. Some +images here are officially supported by the Ubuntu project and some are not; if +an image is on `cdimage.ubuntu.com`, it simply means that it won't fit on +`releases.ubuntu.com`. For example, Ubuntu DVD images are hosted on +`cdimage.ubuntu.com`. + diff --git a/docs/staging/sponsorship-process.md b/docs/staging/sponsorship-process.md new file mode 100644 index 00000000..b9cf0b28 --- /dev/null +++ b/docs/staging/sponsorship-process.md @@ -0,0 +1,154 @@ +(sponsorship-process)= +# Sponsorship process + +```{note} +This content comes [from the wiki](https://wiki.ubuntu.com/SponsorshipProcess) +It has not yet been reviewed for currency or accuracy. +Last updated: 2023 +``` + +The sponsorship process is designed to allow prospective developers to have +packages reviewed and uploaded. Sponsorship provides a means of learning about +Ubuntu development and lowers the entry barrier for contribution. + +The process outlined here is aimed at dealing with incremental changes to +existing packages within Ubuntu. For mentoring on the creation of entirely new +packages, please see the +{ref}`New Packages process `. + +## Requesting Sponsorship + +To make use of Ubuntu merge proposals, follow these steps: + +* [[http://packaging.ubuntu.com/html/getting-set-up.html|set up the tools]] +* [[http://packaging.ubuntu.com/html/udd-intro.html|get the source]] +* [[http://packaging.ubuntu.com/html/fixing-a-bug.html#work-on-a-fix|work on the package]] +* [[DistributedDevelopment/Documentation/SeekingSponsorship|seek sponsorship]] + +```{admonition} Incorrect redirects +:class: important +The first three links in this list point to the old packaging guide, which +automatically redirects to the new packaging guide, but the content in the new +packaging guide hasn't been brought over from the old one? +``` + +The traditional process involves: + +* [File an Ubuntu bug in Launchpad](https://bugs.launchpad.net/ubuntu/+filebug) + or follow up on an existing one. If you think this might be a security update, + please review the security team's + "[Issues that warrant a security update](https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures#Issues.2520that.2520warrant.2520a.2520security.2520update)". + +* Attach your work: + + * In the case of a patch (using the same upstream version), attach your + suggested patch (["Submitting the fix"](https://packaging.ubuntu.com/html/fixing-a-bug.html#submitting-the-fix-and-getting-it-included)). + For security updates, please see the [security update packaging guidelines](https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging). + + * If the package uses a patch system (run `what-patch` in the source tree to + find out), use `edit-patch` to comply with the choice of patch system, then + make sure to follow the [patch tagging guidelines](https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines). + Package-specific patch tags may be documented in `debian/README.source`. + + * Review [our general patch guidelines](https://wiki.ubuntu.com/UbuntuDevelopment/Patches) + that give tips on how to get the patch included upstream as well. + + * In the case of a upstream version update attach the `.diff.gz` file (and + link to the new upstream source if necessary. + +* Subscribe `ubuntu-sponsors` or `ubuntu-security-sponsors` as appropriate + (details below). + +### Packages maintained on Launchpad Code Hosting + +Special attention is required if packages are maintained on Launchpad's Code +Hosting. You might run into a message like this, when getting the source +package: + +``` +$ apt-get source ubuntu-artwork +Reading package lists... Done +Building dependency tree +Reading state information... Done +NOTICE: 'ubuntu-artwork' packaging is maintained in the 'Bzr' version control system at: +https://code.launchpad.net/~ubuntu-art-pkg/ubuntu-artwork/ubuntu +Please use: +bzr get https://code.launchpad.net/~ubuntu-art-pkg/ubuntu-artwork/ubuntu +to retrieve the latest (possible unreleased) updates to the package. +[...] +$ +``` + +In these cases please consider registering a +[merge proposal](https://help.launchpad.net/BranchMergeProposals). It will make +the life of the maintainers a lot easier. + +### Forwarding patches upstream + +Review [Debian/Bugs](https://wiki.ubuntu.com/Debian/Bugs) for more information. + +### New packages + +The process for getting NEW packages (packages which are not in Ubuntu at all +yet) reviewed is explained at {ref}`new-packages`. + +## Getting help + +If you are unsure how to get a package sponsored, would like to add a new +package or submit a patch, or have questions getting your package upstream +into Debian, the Ubuntu Patch Pilots can help. + +To find out how to get in touch, please check the +[program documentation](https://ubuntu.com/community/contribute/ubuntu-development/ubuntu-patch-pilots|program documentation). + +Generally asking for help in `#ubuntu-motu` or `#ubuntu-devel` is definitely on +topic too. :-) + +## Sponsoring + +**To review Ubuntu merge proposals, check out +[these UDD instructions](http://packaging.ubuntu.com/html/udd-uploading.html)**. + +Sponsorship is organized into two teams: + +* [Ubuntu Sponsors](https://launchpad.net/~ubuntu-sponsors) + +* [Ubuntu Security sponsors](https://launchpad.net/~ubuntu-security-sponsors) + +Do not assign a bug to anyone if it needs sponsorship. + +Any Ubuntu developer who is interested in acting as a sponsor is welcome to +apply for membership in the appropriate team. + +You can see the currently pending requests at: + +* `https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-sponsors` + +* `https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-sponsors&field.component=3&field.component=4` + +* `https://bugs.launchpad.net/~ubuntu-security-sponsors/+subscribedbugs` + +Or combined at: + +* **[Sponsoring reports](http://sponsoring-reports.ubuntu.com/)** + +```{note} +Occasionally it may be useful to check if there are non-ubuntu bugs that fail +to be noticed: `https://bugs.launchpad.net/bugs/+bugs?field.subscriber=ubuntu-sponsors` +``` + +The `ubuntu-sponsors` team handles general sponsorship of packages in Ubuntu. +The `ubuntu-security-sponsors` team handles sponsorship of packages in the +`security` pocket for all components. + +## Workflow for review and sponsorship + +If you are processing the universe sponsorship queue, please review the +[Code reviews](https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews), +[MOTU Sponsorship procedure documentation](https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue), +or +[Security team sponsors queue](https://wiki.ubuntu.com/SecurityTeam/SponsorsQueue). + + + +