StableReleaseUpdates
|
Size: 3471
Comment:
|
Size: 4636
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 21: | Line 21: |
| 1. Proposing | 1. Propose |
| Line 28: | Line 28: |
| * 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 31: | Line 32: |
| 2. Preparing | 1. Prepare |
| Line 33: | Line 34: |
| Once an update has been discussed and approved in principle, a patch should be prepared for the stable release. The following criteria apply to any packages modified as part of the update: | 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: |
| Line 35: | Line 36: |
| * The changelog entry and resulting .changes file must include a reference to the corresponding bug report(s), including the approved proposal | * 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 |
| Line 37: | Line 39: |
| * The upload target should be ''release''`-proposed` * XXX more standard checklist items here |
* The upload target must be ''release''`-proposed` |
| Line 40: | Line 41: |
| Uploads which do not meet these criteria will be rejected by an archive administrator and not published. | 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. |
| Line 42: | Line 43: |
| 3. Testing | 1. Upload |
| Line 44: | Line 45: |
| Once the update has been uploaded to `-proposed` and built, it can be reviewed and tested by a wider audience. A copy of the complete source package delta (debdiff) should be attached to the bug report for review. XXX uploader, peer, community | The upload will be reviewed by the archive administrators, and approved if it meets the above criteria. Archive administrators should verify that the package delta matches the debdiff attached to the bug report. |
| Line 46: | Line 47: |
| 4. Releasing | 1. Test |
| Line 48: | Line 49: |
| XXX re-upload to -updates with no changes other than changelog, final signoff | Once the update has been published in `-proposed`, it can be tested by a wider audience. |
| Line 50: | Line 51: |
| 5. Following up | * Notify XXX of the availability of this package for testing * 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) |
| Line 52: | Line 55: |
| XXX monitor Malone for regressions, regression response procedure | 1. Release If testing is successful, you may prepare a second upload to ''release''`-updates`: # * Generate the `.changes` file relative to the stable version of the package (`-v`''version'') * 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` 1. Following up * Add yourself as a bug contact for the package in Launchpad, if you are not one already * For several days after the update is released, monitor Launchpad for bug reports relating to the update * In the event of a regression, immediately notify XXX. |
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 may, under realistic circumstances, directly cause user data to be lost
- Severe regressions from the previous release of Ubuntu
How
- Propose
- 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:
- 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 the resulting discussion thread should be added to the bug report as a comment, usually by CCing bugnumber@bugs.launchpad.net.
- 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:
- 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
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
- The upload will be reviewed by the archive administrators, and approved if it meets the above criteria. Archive administrators should verify that the package delta matches the debdiff attached to the bug report.
- Test
Once the update has been published in -proposed, it can be tested by a wider audience.
- Notify XXX of the availability of this package for testing
- 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)
- Release
If testing is successful, you may prepare a second upload to release-updates:
# * Generate the .changes file relative to the stable version of the package (-vversion)
- 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
- Following up
- Add yourself as a bug contact for the package in Launchpad, if you are not one already
- For several days after the update is released, monitor Launchpad for bug reports relating to the update
- In the event of a regression, immediately notify XXX.
StableReleaseUpdates (last edited 2024-05-14 20:50:50 by mfo)