StableReleaseUpdates
Size: 2780
Comment: continue drafting
|
Size: 9207
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 13: | Line 13: |
Stable release updates will, in general, only be issued in order to fix "high-impact" bugs. Examples of such bugs include: | Stable release updates will, in general, only be issued in order to fix '''high-impact bugs'''. Examples of such bugs include: |
Line 15: | Line 15: |
* Security vulnerabilities * Severe regressions from the previous release of Ubuntu * Bugs which may, under realistic circumstances, directly cause user data to be lost |
* Bugs which may, under realistic circumstances, directly cause a '''security vulnerability''' * Bugs which represent '''severe regressions''' from the previous release of Ubuntu * Bugs which may, under realistic circumstances, directly cause a '''loss of user data''' |
Line 21: | Line 21: |
1. Proposing the update | This process is to be followed for all updates '''except''' those to fix security updates, which are only released by the Ubuntu security team. Security procedures are documented at SecurityUpdateProcedures. For updates to source packages in the `universe` or `multiverse` components, see ["MOTU/SRU"]. Any `main` source packages with binary packages that cross components will have all of their packages examined under this policy. 1. Propose |
Line 23: | Line 27: |
All proposals for stable release updates must first be discussed with XXX and be approved by XXX. Proposals must be accompanied by the following information for each bug to be addressed: | All proposals for stable release updates must be '''approved''' by Matt Zimmerman or Colin Watson. A convenient way to do this is to attach all of the information to the existing bug report, use ''Backport fix to releases'' to mark the bug for backporting, then subscribe the `ubuntu-sru` team. If more than one bug is being addressed, it is better to file a bug to track the SRU itself and refer to all of the relevant bugs. SRU proposals ''must'' be accompanied by the following information for each bug to be addressed: |
Line 25: | Line 29: |
* A bug number referring to a complete bug report describing the problem and its effect * A statement explaining the impact of the bug on users and justification for backporting the fix to the stable release * An explanation of how the bug has been addressed in the development branch, including the relevant version numbers of packages modified in order to implement the fix |
* A '''bug number''' referring to a complete bug report describing the problem and its effect * A '''statement explaining the impact''' of the bug on users and justification for backporting the fix to the stable release * An explanation of '''how the bug has been addressed''' in the development branch, including the relevant version numbers of packages modified in order to implement the fix * A '''patch''' applicable to the stable version of the package. If preparing a patch is likely to be time-consuming, it may be preferable to discuss the first three items before preparing a patch. |
Line 29: | Line 34: |
A copy of this proposal and a hyperlink to the resulting discussion thread should be added to the bug report as a comment, usually by CCing ''bugnumber''`@bugs.launchpad.net`. | A copy of this proposal and a hyperlink to any prior discussion thread should be added to the bug report as a comment, usually by CCing ''bugnumber''`@bugs.launchpad.net`. |
Line 31: | Line 36: |
2. Preparing the update | Each bug report must have its '''Description''' updated to include the impact, how the bug is addressed, and the patch that resolves it. |
Line 33: | Line 38: |
Once an update has been discussed and approved in principle, a patch may be prepared for the stable release. The following criteria apply to any packages modified as part of the update: | 1. Prepare |
Line 35: | Line 40: |
* The changelog entry and resulting .changes file must include a reference to the corresponding bug report(s) * The version number must be carefully checked in order to avoid clashing with any other version of the package, past, present or future * The upload target should be ''release''`-proposed` |
Once an update has been discussed and approved in principle, an upload can be prepared. The following criteria apply to any packages modified as part of the update: * The changelog entry and resulting .changes file must include a reference to the corresponding '''bug report(s)''' * The bug report must include an '''approved SRU proposal''' * The '''version number(s)''' must be carefully checked in order to avoid clashing with any other version of the package, past, present or future * The upload target must be ''release''`-proposed` * The package difference must be a minimal change to fix the bug. Spurious changes to build systems, documentation, functionality ''will be rejected''. * Make sure to generate the `.changes` file against the base version in the relevant distribution and not against the version in `-proposed` or a previous version in `-updates`, using the `-v` option to `dpkg-buildpackage` or `debuild`. Uploads which do not meet these criteria will be '''rejected''' by an archive administrator and not published. Once the upload is ready, attach a complete source package diff (`debdiff`) to the bug report for review. 1. Upload Once you have uploaded the package, subscribe the `ubuntu-archive` team to the bug report so that it shows up on the archive administrators' to-do list. The upload will be reviewed by the archive administrators during regularly scheduled processing, and approved if it meets the above criteria. Archive administrators should verify that the package delta matches the debdiff attached to the bug report. The `ubuntu-archive` team member who accepts the package into `-proposed` should: * Add a `verification-needed` tag to the bug report. * Set the bug report to '''Status: Fix Committed'''. 1. Test Once the update has been published in `-proposed`, it can be tested by a wider audience. * Notify the QA team via Simon Law [mailto:sfllaw@ubuntu.com <sfllaw@ubuntu.com>] of the availability of this package for testing * Prepend "StableReleaseUpdates" to the Subject line of your e-mail. * Test the package yourself * If the update has the potential for hardware-specific effects, request a hardware support regression test via the QA team (for example, kernel updates) The QA team may discover that your fix is insufficient. They will: * Set the bug report '''Status: In Progress''' * Describe why the fix was rejected in a comment to the bug report. The QA team may also discover that your fix is good. They will: * Add a `verification-done` tag to the bug report. * Notify the archive team via [mailto:ubuntu-archive@lists.ubuntu.com ubuntu-archive@lists.ubuntu.com] that it is approved by QA * Describe the general steps taken to verify the package, any special difficulties, and the recommended upload date. 1. Release After the package in `-proposed` has been successfully tested and passed a minimum aging period of '''7 days''', and is approved for upload to ''release''`-updates` by the QA team (Simon Law), you may prepare a second upload to ''release''`-updates`: * Include a changelog entry with: * A new version number (the same cautions apply regarding the choice of version number) * '''Confirmation of the above testing''', including the name of the tester in each case * Make '''no other changes''' relative to the version in `-proposed`. * Make sure to generate the `.changes` file against the base version in the relevant distribution and not against the version in `-proposed` or a previous version in `-updates`, using the `-v` option to `dpkg-buildpackage` or `debuild`. The archive administrators must verify that uploads to `-updates` meet these criteria. In the future, the update from `-proposed` will be copied verbatim instead, once the necessary infrastructure is available. 1. Follow up * Add yourself as a '''bug contact''' for the package in Launchpad, if you are not one already * For 7 days after the update is released, '''monitor Launchpad''' for bug reports relating to the update * In the event of a regression, '''immediately''' notify the [mailto:technical-board@lists.ubuntu.com Ubuntu Technical Board] via email, and ask for help on `#ubuntu-devel` in making urgent contact with a member of the Board. == Special Cases == === Kernel === Because of the way updates to the kernel work, it will follow a slightly different process. The following reasons call for this exception: * The kernel is uploaded frequently to -security, so uploading to -updates is not possible due to frequent version skew in the kernel and supporting packages (linux-restricted-modules, linux-meta, etc). * Kernel packages are not copied from `-proposed` to `-updates` or `-security` * A facility is needed for staging updates to the kernel in bulk, and `-proposed` is the closest fit Therefore the following differences apply: * Updates for the kernel will be routinely uploaded to `-proposed` with a specially chosen ABI version (and therefore package name) to avoid clashing with any other kernel installed in the field. Users will not be automatically upgraded to this kernel. * No prior discussion and approval is needed for kernel updates to `-proposed` * Individual kernel patches, rather than complete packages, will go through the SRU process above, after having been staged in `-proposed` (This section is based on discussions between AdamConrad, MattZimmerman and BenCollins) == Examples == As reference you can lookup [https://launchpad.net/distros/ubuntu/+source/cpio/+bug/59228] to have an idea on how the procedure works. |
Once an Ubuntu release has been completed and published, updates for it are only released under certain circumstances, and must follow a special procedure.
Why
In contrast to pre-release versions, official releases of Ubuntu are subject to much wider use, and by a different demographic of user. During development, changes to the distribution primarily affect developers, early adopters and other advanced users, all of whom have elected to use pre-release software at their own risk.
Users of the official release, in contrast, expect a high degree of stability. They use their Ubuntu system for their day-to-day work, and problems they experience with it can be extremely disruptive. Many of them are less experienced with Ubuntu and with Linux, and expect a reliable system which does not require their intervention.
Stable release updates are automatically recommended to a very large number of users, and so it is critically important to treat them with great caution. Therefore, when updates are proposed, they must be accompanied by a strong rationale and present a low risk of regressions.
When
Stable release updates will, in general, only be issued in order to fix high-impact bugs. Examples of such bugs include:
Bugs which may, under realistic circumstances, directly cause a security vulnerability
Bugs which represent severe regressions from the previous release of Ubuntu
Bugs which may, under realistic circumstances, directly cause a loss of user data
How
This process is to be followed for all updates except those to fix security updates, which are only released by the Ubuntu security team. Security procedures are documented at SecurityUpdateProcedures.
For updates to source packages in the universe or multiverse components, see ["MOTU/SRU"]. Any main source packages with binary packages that cross components will have all of their packages examined under this policy.
- Propose
All proposals for stable release updates must be approved by Matt Zimmerman or Colin Watson. A convenient way to do this is to attach all of the information to the existing bug report, use Backport fix to releases to mark the bug for backporting, then subscribe the ubuntu-sru team. If more than one bug is being addressed, it is better to file a bug to track the SRU itself and refer to all of the relevant bugs. SRU proposals must be accompanied by the following information for each bug to be addressed:
A bug number referring to a complete bug report describing the problem and its effect
A statement explaining the impact of the bug on users and justification for backporting the fix to the stable release
An explanation of how the bug has been addressed in the development branch, including the relevant version numbers of packages modified in order to implement the fix
A patch applicable to the stable version of the package. If preparing a patch is likely to be time-consuming, it may be preferable to discuss the first three items before preparing a patch.
A copy of this proposal and a hyperlink to any prior discussion thread should be added to the bug report as a comment, usually by CCing bugnumber@bugs.launchpad.net.
Each bug report must have its Description updated to include the impact, how the bug is addressed, and the patch that resolves it.
- Prepare
- Once an update has been discussed and approved in principle, an upload can be prepared. The following criteria apply to any packages modified as part of the update:
The changelog entry and resulting .changes file must include a reference to the corresponding bug report(s)
The bug report must include an approved SRU proposal
The version number(s) must be carefully checked in order to avoid clashing with any other version of the package, past, present or future
The upload target must be release-proposed
The package difference must be a minimal change to fix the bug. Spurious changes to build systems, documentation, functionality will be rejected.
Make sure to generate the .changes file against the base version in the relevant distribution and not against the version in -proposed or a previous version in -updates, using the -v option to dpkg-buildpackage or debuild.
Uploads which do not meet these criteria will be rejected by an archive administrator and not published. Once the upload is ready, attach a complete source package diff (debdiff) to the bug report for review.
- Once an update has been discussed and approved in principle, an upload can be prepared. The following criteria apply to any packages modified as part of the update:
- Upload
Once you have uploaded the package, subscribe the ubuntu-archive team to the bug report so that it shows up on the archive administrators' to-do list. The upload will be reviewed by the archive administrators during regularly scheduled processing, and approved if it meets the above criteria. Archive administrators should verify that the package delta matches the debdiff attached to the bug report.
The ubuntu-archive team member who accepts the package into -proposed should:
Add a verification-needed tag to the bug report.
Set the bug report to Status: Fix Committed.
- Test
Once the update has been published in -proposed, it can be tested by a wider audience.
Notify the QA team via Simon Law [mailto:sfllaw@ubuntu.com <sfllaw@ubuntu.com>] of the availability of this package for testing
Prepend "StableReleaseUpdates" to the Subject line of your e-mail.
- Test the package yourself
- If the update has the potential for hardware-specific effects, request a hardware support regression test via the QA team (for example, kernel updates) The QA team may discover that your fix is insufficient. They will:
Set the bug report Status: In Progress
- Describe why the fix was rejected in a comment to the bug report. The QA team may also discover that your fix is good. They will:
Add a verification-done tag to the bug report.
Notify the archive team via [mailto:ubuntu-archive@lists.ubuntu.com ubuntu-archive@lists.ubuntu.com] that it is approved by QA
- Describe the general steps taken to verify the package, any special difficulties, and the recommended upload date.
- Release
After the package in -proposed has been successfully tested and passed a minimum aging period of 7 days, and is approved for upload to release-updates by the QA team (Simon Law), you may prepare a second upload to release-updates:
- Include a changelog entry with:
- A new version number (the same cautions apply regarding the choice of version number)
Confirmation of the above testing, including the name of the tester in each case
Make no other changes relative to the version in -proposed.
Make sure to generate the .changes file against the base version in the relevant distribution and not against the version in -proposed or a previous version in -updates, using the -v option to dpkg-buildpackage or debuild.
The archive administrators must verify that uploads to -updates meet these criteria. In the future, the update from -proposed will be copied verbatim instead, once the necessary infrastructure is available.
- Follow up
Add yourself as a bug contact for the package in Launchpad, if you are not one already
For 7 days after the update is released, monitor Launchpad for bug reports relating to the update
In the event of a regression, immediately notify the [mailto:technical-board@lists.ubuntu.com Ubuntu Technical Board] via email, and ask for help on #ubuntu-devel in making urgent contact with a member of the Board.
Special Cases
Kernel
Because of the way updates to the kernel work, it will follow a slightly different process. The following reasons call for this exception:
- The kernel is uploaded frequently to -security, so uploading to -updates is not possible due to frequent version skew in the kernel and supporting packages (linux-restricted-modules, linux-meta, etc).
Kernel packages are not copied from -proposed to -updates or -security
A facility is needed for staging updates to the kernel in bulk, and -proposed is the closest fit
Therefore the following differences apply:
Updates for the kernel will be routinely uploaded to -proposed with a specially chosen ABI version (and therefore package name) to avoid clashing with any other kernel installed in the field. Users will not be automatically upgraded to this kernel.
No prior discussion and approval is needed for kernel updates to -proposed
Individual kernel patches, rather than complete packages, will go through the SRU process above, after having been staged in -proposed
(This section is based on discussions between AdamConrad, MattZimmerman and BenCollins)
Examples
As reference you can lookup [https://launchpad.net/distros/ubuntu/+source/cpio/+bug/59228] to have an idea on how the procedure works.
StableReleaseUpdates (last edited 2024-06-17 13:29:05 by racb)