Table of Contents
NOTE: This process is undergoing change, the content below may be updated
Ubuntu Backports Process
This page documents the development process for the Ubuntu Backports Project, as well as some of the justification for the project’s policies. If you’re not familiar with what backports are, or are trying to figure out how to install a package backported through the Backports Project, then our user documentation might be a good place to start.
The procedure is intentionally very similar to the existing SRU procedure, with minor changes specific to the purpose of the backports pocket. You should first read and understand that process, as this will page will only highlight the specific differences, and assumes you are familiar with the SRU process.
Open a Bug
The first step is to open a bug in Launchpad for the backport. Open the bug against the package that you want backported, and include the prefix [BPO] in the bug subject line. The bug description should include the BPO bug template, filled out with specific details for the requested backport.
Unlike the SRU process, which does not allow requesting a SRU to add features or functionality, the backport process does allow the need for new features or functionality. The backport bug does not need to list all fixed bugs or all new functionality, but should highlight and/or summarize the key fixes or features or other reasons for needing to backport the package.
The bug's intention is to provide a location for any paperwork that might be required for the backport, for example if any questions are raised during review or if any discussion is required, as well as providing a reference for anyone who might want to later see why and how a specific package was backported.
Preparing the Backported Package
As in the SRU process, you must prepare a package for the backport. If you have upload rights, you can then upload directly into the backports queue. Note that unlike uploading for SRU, when uploading into the backports queue, you should use the backports pocket; for example, in the changelog instead of using the release focal you should use focal-backports. Additionally, the version number you use should exactly match the version number you are backporting from, with a specific suffix added in the format ~bpoRELEASE.1, for example if backporting to release 20.04, append the suffix ~bpo20.04.1.
Finding a Sponsor
If you do not have upload rights, and/or if you are unfamiliar with preparing packages for upload, you will need to find a sponsor, similar to the SRU process. You can request sponsorship in the same way as the SRU process.
In the SRU process, a debdiff is preferred, however since the backport process typically will include a much larger change in code, you may want to simply link to a PPA where you have a backported build prepared; but it will be up to your sponsor to determine what format they would like you to provide the backported package for them to review and upload.
Reason for Backport
Backports are intended to provide new features to older releases, and as such it is generally not acceptable to request a backport to only fix bugs that could be fixed using the normal SRU process. Any exception to this would need to be approved by the Ubuntu Backporters team on a case-by-case basis, with the requestor providing reasoning for why the bug should be fixed with a backport instead of using the SRU process.
One specific exception is the case of updating an existing backport; once a package has been approved for backporting, it may be updated for normal security patches and bug fixes that are added to the package in the later Ubuntu release where it is backported from. Future monitoring of the package is the responsibility of the backport requestor.
Another exception is any package that the backports team has already identified as eligible for backporting; a list of such packages is located TBD.
The Backports Project only backports packages from within the Ubuntu repositories. If a package is not yet available in the Ubuntu archive (perhaps because it is a new package, or because it has not yet been updated to the requested version), it is not a candidate for backporting.
Ensuring a Safe Upgrade Path
When a user upgrades from one Ubuntu release to the next, the version of any given package installed on his or her machine should be available in the Ubuntu release that user is running, assuming the package came from Ubuntu initially. For backported packages, the policy is that users must be able to upgrade from LTS to LTS. This policy specifically means that backports are allowed for interim (non-LTS) releases, but are not required.
Responsibilities of Backport Requestor
Preparing the Backport
As mentioned above, you (or your sponsor) will need to prepare the backported package. This should be done with as few changes as possible to the backported package; any changes required should be explicitly stated in the changelog entry of the backported package.
Testing the Backport
You must test the backport in the Ubuntu release(s) you are requesting the backport for.
Functionality of the Backported Package
Each package being backported must install cleanly and without errors. The software in each package must also run. You must detail your test process and results in the bug. This testing should cover as much of the package functionality as possible, not just any missing functionality or feature that you are requesting the backport for.
Continued Functionality of Reverse-Dependencies
In addition to the backported package itself working, any other software that depends on the backported package must continue to run with the backported package installed, and any package that has a build-dependency on the backported package must build with the new package installed.
Future Maintenance of the Backport
The person requesting the backport is responsible for monitoring the backported package in the future for any bug reports, security patches, or additional updates that should be backported. The Ubuntu Backports team is not responsible for the backported package, and future backports should use this same backports process.
BPO Bug Template
[Impact] * Justification for backporting the new version to the stable release. [Scope] * List the Ubuntu release you will backport from, and the specific package version. * List the Ubuntu release(s) you will backport to. [Other Info] * Anything else you think is useful to include