StableReleaseUpdates
|
Size: 2780
Comment: continue drafting
|
Size: 15963
Comment: mention failed/not happening verification
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| Once an Ubuntu release has been completed and published, updates for it are only released under certain circumstances, and must follow a special procedure. | ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>|| Once an Ubuntu release has been completed and published, updates for it are only released under certain circumstances, and must follow a special procedure called a "stable release update" or SRU. There is an automatically generated list of [[http://people.ubuntu.com/~ubuntu-archive/pending-sru.html|packages which are currently undergoing this process]]. |
| Line 11: | Line 15: |
| === It's just a one-line change! === Even the simplest of changes can cause unexpected regressions due to lurking problems. In [[https://bugs.launchpad.net/bugs/81125|bug 81125]], the upgrade regression had nothing to do with the content of the change that triggered it: any user who had installed the libpthread20 package would encounter a problem the next time libc6 was upgraded. In [[https://bugs.launchpad.net/bugs/309674|bug 309674]], the failure was a misbuild due to timestamp skew in the build process. The underlying problem existed in the source package in the original release, but would only manifest in a small percentage of builds. Citizen, be paranoid, and expect the unexpected. |
|
| Line 13: | Line 27: |
| 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 29: |
| * 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'''. These are done by the security team and are documented at SecurityTeam/UpdateProcedures. * Bugs which represent '''severe regressions''' from the previous release of Ubuntu. This includes packages which are totally unusable, like being uninstallable or crashing on startup. * Bugs which may, under realistic circumstances, directly cause a '''loss of user data''' * Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel). * For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure to not affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. * New versions of commercial software in the Canonical partner archive. * '''FTBFS'''(Fails To Build From Source) can also be considered. Please note that in '''main''' the release process ensures that there are no binaries which are not built from a current source. Usually those bugs should only be SRUed in conjunction with another bug fix. |
| Line 19: | Line 37: |
| == How == | For new upstream versions of packages which provide new features, but don't fix critical bugs, a [[https://help.ubuntu.com/community/UbuntuBackports|backport]] should be requested instead. |
| Line 21: | Line 39: |
| 1. Proposing the update 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: |
== Procedure == |
| Line 25: | Line 41: |
| * 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 |
1. Check that the bug is fixed in the current development release, and that its bug report task is "Fix released". It is, in general, not appropriate to release bug fixes for stable systems without first testing them in the current development branch. |
| Line 29: | Line 43: |
| 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`. | 1. Update the bug report description and make sure it contains the following information: 1. A '''statement explaining the impact''' of the bug on users and justification for backporting the fix to the stable release 1. 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. 1. A minimal '''patch''' applicable to the stable version of the package. If preparing a patch is likely to be time-consuming, it may be preferable to get a general approval from the SRU team first. 1. Detailed '''instructions''' how to reproduce the bug. These should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. Please mark this with a line "{{{TEST CASE:}}}". 1. A '''discussion''' of the regression potential of the patch and how users could get inadvertently affected. |
| Line 31: | Line 50: |
| 2. Preparing the update | 1. Use ''Nominate for release'' to mark the bug as an SRU candidate for the appropriate Ubuntu releases (e. g. the current LTS and latest stable release), then subscribe [[https://launchpad.net/~ubuntu-sru|ubuntu-sru]] for packages in main/restricted, or [[https://launchpad.net/~motu-sru|motu-sru]] for packages in universe/multiverse. |
| Line 33: | Line 52: |
| 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. Upload the fixed package to ''release''`-proposed` with the patch in the bug report, a detailed and user-readable changelog, and no other unrelated changes. Make sure that the version number does not conflict with any later and future version in other Ubuntu releases (the [[https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update%20the%20packaging|security policy document]] has a well-working scheme which can be used for SRUs.) Also be sure to reference the SRU bug number in the changelog using the 'LP: #NNNNNN' convention. |
| Line 35: | Line 54: |
| * 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` |
1. Once the [[https://wiki.ubuntu.com/ArchiveAdministration#Stable release updates|archive admins approve and publish your upload]], test the actual binaries in the Ubuntu archive yourself and follow up in the bug report. 1. Subscribe yourself to bugmail for the package in Launchpad, if you haven't done so already, and '''monitor Launchpad''' for bug reports relating to the update for at least one week. <<Anchor(regressions)>> 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 or the SRU team: state the problem, the bug number, and ping "slangasek, Riddell, Hobbsee, pitti, mdz, Keybuk, cjwatson, kees, jdstrand, BenC, dendrobates, davidm". For SRU in universe/multiverse, contact the [[mailto:ubuntu-motu@lists.ubuntu.com|Universe SRU Team]] team or ask for help on `#ubuntu-motu` instead. Any regression must '''always''' be documented in a bug report, which must be ''Importance: critical'' once the regression has been confirmed. == Fixing several bugs in one upload == Please avoid creating meta-bugs like "Please SRU this". They just create redundancy and are opaque to original bug reporters, whose feedback is valuable for verification. Just prepare all fixed bugs as described above and attach the patch/debdiff to one of them. In order to make it easier for the SRU team to review your patch, you can additionally: * Point to the patch/debdiff in the other bugs ("debdiff which fixes this is attached to bug #xxxxxx") * Attach individual patches to the corresponding bug reports. If you have the fixes in bzr, it is even easier and more convenient to give a pointer to the fix ("fixed in http://bazaar.launchpad.net/.../revision/12") when fixing the bug in trunk. == Verification == The [[https://launchpad.net/~sru-verification|SRU verification team]] will regularly check open bugs with the `verification-needed` tag and test proposed updates on different hardware to check for inadvertent side effects. Verification must be done in a software environment as close as is feasible to that which will exist after the package is copied to *-updates. Generally this will be with a system that is up to date from *-release, *-security, and *-updates, but not other packages from *-proposed (except other packages built from the affected source package - they must be updated if generally installed) or *-backports. If they discover that your fix is insufficient, or the test case is not sufficient to reproduce the bug, they will: 1. Set the bug report '''Status: In Progress''' 1. Describe why the fix was rejected in a comment to the bug report. 1. Modify the `verification-needed tag` to a `verification-failed` tag on the bug report. The SRU verification team may also discover that your fix is good. They will: 1. Modify the `verification-needed` tag to a `verification-done` tag on the bug report. 1. Describe the general steps taken to verify the package, any special difficulties, and the recommended upload date. Verification feedback from bug reporters and subscribers is greatly appreciated, too, especially if the update is hardware specific. In this case we consider an update as verified if it has at least two positive and no negative testimonials in the bug report, and the verification team just checks whether the new version still works for the main use cases (to check for major regressions). If you encounter a regression in a package that has been uploaded to *-proposed, please: 1. File a bug report against the package, describing the nature of the regression you have encountered, including any special steps needed to reproduce the regression. 1. Mark this bug with the tag `regression-proposed` 1. Use the `Nominate for release` link to highlight the bug for the release involved. 1. Follow up to the SRU bug report referenced from the package changelog, pointing to the new bug. If there is more than one bug in the SRU changelog, follow up to the bug that is most closely related to the regression. 1. Set the `verification-failed` tag on the corresponding SRU bug report. == Removal of updates == If an update does not get any testing/verification feedback for more than half a year, despite several calls for testing, the Stable Release Managers will remove the package from -proposed and usually close the bug task as "wontfix", due to lack of interest. Removal will happen immediately if a package update in -proposed is found to introduce a nontrivial regression. <<Anchor(Special)>> == Special Cases == The [[https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-March/000550.html|Technical Board resolution on Landscape]] provides a general rationale for the types of special cases that may be approved here in future. === New micro releases === For some packages it is acceptable to upload new upstream microreleases to stable Ubuntu releases. See /MicroReleaseExceptions for details. === Kernel === Because of the way updates to the kernel work, it will follow a slightly different process which is described on KernelTeam/KernelUpdates. === app-install-data-commercial === The app-install-data-commercial source package may be uploaded to add .desktop files for new packages in the commercial repository on archive.canonical.com. This does not require prior approval, and the aging requirement is waived; but it must still go through -proposed, a bug report must still be filed with testing instructions (its enough to add the new apps so that the tester can try to install them and verify that this works), and testing must still be recorded in the bug report. (This section is based on discussions between MichaelVogt and ColinWatson) === Landscape === The landscape-client source package may be uploaded according to the procedure documented in LandscapeUpdates. See the [[https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-March/000550.html|Technical Board resolution]] for details and rationale. === tzdata === The tzdata package is updated to reflect changes in timezones or daylight saving policies. The verification is done with the "zdump" utility. The first timezone that gets changed in the updated package is dumped with "zdump -v $region/$timezone_that_changed" (this needed to be greped for in /usr/share/zoneinfo/). This is compared to the same output after the updated package got installed. If those are different the verification is considered done. === hal-info === The hal-info package contains descriptions, quirks, and other information about hardware components, in particular for suspend/resume, Laptop Fn keys, broken batteries, and multimedia devices. It gets frequent updates in stable LTS releases. After one week of maturing in -proposed and no regression bug reports it can be moved to -updates. === mobile-broadband-provider-info === Whenever there are significant changes, a new version is uploaded into the current development release and all stable releases from 8.10 on. After one week of maturing in -proposed and no regression bug reports it can be moved to -updates. === clamav and rdepends === Due to the special evolving nature of anti-virus requirements and the complexity of maintaining security fixes for multiple releases, we will work to keep clamav current on all supported releases. See ClamavUpdates for details. === sun-java* === Ubuntu 9.04 and later include an officially tested and certified JDK called OpenJDK. Prior to Ubuntu 9.04, the only officially tested and certified JDKs were `sun-java5` and `sun-java6`. These are binary-only packages shipped in multiverse. To support users of 8.04 LTS who do not have access to the free OpenJDK, new upstream microreleases of `sun-java5` and `sun-java6` can be provided in -updates without checking individual changes for above SRU criteria for as long as Sun as provides updates. Verification just needs to prove that the packages still upgrade/install for users, and that Java applications and browser applets still run, using the packages from hardy-proposed. Other users are recommended to upgrade to at least 9.04 and use the supported OpenJDK. When upstream discontinues maintenance for a version of a sun-java* package (e.g. sun-java5), no more updates will be provided for that package. An announcement should be made to the ubuntu-devel-announce mailing list regarding the discontinued support of the affected package. == Examples == As a reference, see [[https://launchpad.net/bugs/173082|bug #173082]] for an idea of how the SRU process works for a main package, or [[https://launchpad.net/bugs/208666|bug #208666]] for an SRU in universe. == Links == Note that `ubuntu-sru`'s subscribed bugs page may not be sufficient to catch bugs that (a) are Fix Released in the current development release and (b) have been nominated but not approved for stable releases. See the following links: * [[https://bugs.edge.launchpad.net/ubuntu/dapper/+nominations?field.subscriber=ubuntu-sru|Dapper]] * [[https://bugs.edge.launchpad.net/ubuntu/hardy/+nominations?field.subscriber=ubuntu-sru|Hardy]] * [[https://bugs.edge.launchpad.net/ubuntu/intrepid/+nominations?field.subscriber=ubuntu-sru|Intrepid]] * [[https://bugs.edge.launchpad.net/ubuntu/jaunty/+nominations?field.subscriber=ubuntu-sru|Jaunty]] === Useful links for motu-sru === * [[http://qa.ubuntuwire.com/sru/todo.html|Bugs in different stages of the MOTU stable release process]] * [[https://bugs.launchpad.net/~motu-sru/|Bugs subscribed by motu-sru in launchpad]] * List of bugs which needs verification for [[http://tinyurl.com/3bgr3y|Dapper]], [[http://tinyurl.com/yr7wsu|Gutsy]] * List of verified bugs for [[http://tinyurl.com/25f6dk|Dapper]], [[http://tinyurl.com/yuk7s7|Gutsy]] ---- CategoryProcess |
Once an Ubuntu release has been completed and published, updates for it are only released under certain circumstances, and must follow a special procedure called a "stable release update" or SRU.
There is an automatically generated list of packages which are currently undergoing this process.
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.
It's just a one-line change!
Even the simplest of changes can cause unexpected regressions due to lurking problems.
In bug 81125, the upgrade regression had nothing to do with the content of the change that triggered it: any user who had installed the libpthread20 package would encounter a problem the next time libc6 was upgraded.
In bug 309674, the failure was a misbuild due to timestamp skew in the build process. The underlying problem existed in the source package in the original release, but would only manifest in a small percentage of builds.
Citizen, be paranoid, and expect the unexpected.
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. These are done by the security team and are documented at SecurityTeam/UpdateProcedures.
Bugs which represent severe regressions from the previous release of Ubuntu. This includes packages which are totally unusable, like being uninstallable or crashing on startup.
Bugs which may, under realistic circumstances, directly cause a loss of user data
- Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel).
- For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure to not affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers.
- New versions of commercial software in the Canonical partner archive.
FTBFS(Fails To Build From Source) can also be considered. Please note that in main the release process ensures that there are no binaries which are not built from a current source. Usually those bugs should only be SRUed in conjunction with another bug fix.
For new upstream versions of packages which provide new features, but don't fix critical bugs, a backport should be requested instead.
Procedure
- Check that the bug is fixed in the current development release, and that its bug report task is "Fix released". It is, in general, not appropriate to release bug fixes for stable systems without first testing them in the current development branch.
- Update the bug report description and make sure it contains the following information:
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 minimal patch applicable to the stable version of the package. If preparing a patch is likely to be time-consuming, it may be preferable to get a general approval from the SRU team first.
Detailed instructions how to reproduce the bug. These should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. Please mark this with a line "TEST CASE:".
A discussion of the regression potential of the patch and how users could get inadvertently affected.
Use Nominate for release to mark the bug as an SRU candidate for the appropriate Ubuntu releases (e. g. the current LTS and latest stable release), then subscribe ubuntu-sru for packages in main/restricted, or motu-sru for packages in universe/multiverse.
Upload the fixed package to release-proposed with the patch in the bug report, a detailed and user-readable changelog, and no other unrelated changes. Make sure that the version number does not conflict with any later and future version in other Ubuntu releases (the security policy document has a well-working scheme which can be used for SRUs.) Also be sure to reference the SRU bug number in the changelog using the 'LP: #NNNNNN' convention.
Once the archive admins approve and publish your upload, test the actual binaries in the Ubuntu archive yourself and follow up in the bug report.
Subscribe yourself to bugmail for the package in Launchpad, if you haven't done so already, and monitor Launchpad for bug reports relating to the update for at least one week.
In the event of a regression, immediately notify the Ubuntu Technical Board via email, and ask for help on #ubuntu-devel in making urgent contact with a member of the Board or the SRU team: state the problem, the bug number, and ping "slangasek, Riddell, Hobbsee, pitti, mdz, Keybuk, cjwatson, kees, jdstrand, BenC, dendrobates, davidm". For SRU in universe/multiverse, contact the Universe SRU Team team or ask for help on #ubuntu-motu instead.
Any regression must always be documented in a bug report, which must be Importance: critical once the regression has been confirmed.
Fixing several bugs in one upload
Please avoid creating meta-bugs like "Please SRU this". They just create redundancy and are opaque to original bug reporters, whose feedback is valuable for verification. Just prepare all fixed bugs as described above and attach the patch/debdiff to one of them.
In order to make it easier for the SRU team to review your patch, you can additionally:
- Point to the patch/debdiff in the other bugs ("debdiff which fixes this is attached to bug #xxxxxx")
Attach individual patches to the corresponding bug reports. If you have the fixes in bzr, it is even easier and more convenient to give a pointer to the fix ("fixed in http://bazaar.launchpad.net/.../revision/12") when fixing the bug in trunk.
Verification
The SRU verification team will regularly check open bugs with the verification-needed tag and test proposed updates on different hardware to check for inadvertent side effects. Verification must be done in a software environment as close as is feasible to that which will exist after the package is copied to *-updates. Generally this will be with a system that is up to date from *-release, *-security, and *-updates, but not other packages from *-proposed (except other packages built from the affected source package - they must be updated if generally installed) or *-backports.
If they discover that your fix is insufficient, or the test case is not sufficient to reproduce the bug, they will:
Set the bug report Status: In Progress
- Describe why the fix was rejected in a comment to the bug report.
Modify the verification-needed tag to a verification-failed tag on the bug report.
The SRU verification team may also discover that your fix is good. They will:
Modify the verification-needed tag to a verification-done tag on the bug report.
- Describe the general steps taken to verify the package, any special difficulties, and the recommended upload date.
Verification feedback from bug reporters and subscribers is greatly appreciated, too, especially if the update is hardware specific. In this case we consider an update as verified if it has at least two positive and no negative testimonials in the bug report, and the verification team just checks whether the new version still works for the main use cases (to check for major regressions).
If you encounter a regression in a package that has been uploaded to *-proposed, please:
- File a bug report against the package, describing the nature of the regression you have encountered, including any special steps needed to reproduce the regression.
Mark this bug with the tag regression-proposed
Use the Nominate for release link to highlight the bug for the release involved.
- Follow up to the SRU bug report referenced from the package changelog, pointing to the new bug. If there is more than one bug in the SRU changelog, follow up to the bug that is most closely related to the regression.
Set the verification-failed tag on the corresponding SRU bug report.
Removal of updates
If an update does not get any testing/verification feedback for more than half a year, despite several calls for testing, the Stable Release Managers will remove the package from -proposed and usually close the bug task as "wontfix", due to lack of interest. Removal will happen immediately if a package update in -proposed is found to introduce a nontrivial regression.
Special Cases
The Technical Board resolution on Landscape provides a general rationale for the types of special cases that may be approved here in future.
New micro releases
For some packages it is acceptable to upload new upstream microreleases to stable Ubuntu releases. See /MicroReleaseExceptions for details.
Kernel
Because of the way updates to the kernel work, it will follow a slightly different process which is described on KernelTeam/KernelUpdates.
app-install-data-commercial
The app-install-data-commercial source package may be uploaded to add .desktop files for new packages in the commercial repository on archive.canonical.com. This does not require prior approval, and the aging requirement is waived; but it must still go through -proposed, a bug report must still be filed with testing instructions (its enough to add the new apps so that the tester can try to install them and verify that this works), and testing must still be recorded in the bug report.
(This section is based on discussions between MichaelVogt and ColinWatson)
Landscape
The landscape-client source package may be uploaded according to the procedure documented in LandscapeUpdates. See the Technical Board resolution for details and rationale.
tzdata
The tzdata package is updated to reflect changes in timezones or daylight saving policies. The verification is done with the "zdump" utility. The first timezone that gets changed in the updated package is dumped with "zdump -v $region/$timezone_that_changed" (this needed to be greped for in /usr/share/zoneinfo/). This is compared to the same output after the updated package got installed. If those are different the verification is considered done.
hal-info
The hal-info package contains descriptions, quirks, and other information about hardware components, in particular for suspend/resume, Laptop Fn keys, broken batteries, and multimedia devices. It gets frequent updates in stable LTS releases. After one week of maturing in -proposed and no regression bug reports it can be moved to -updates.
mobile-broadband-provider-info
Whenever there are significant changes, a new version is uploaded into the current development release and all stable releases from 8.10 on. After one week of maturing in -proposed and no regression bug reports it can be moved to -updates.
clamav and rdepends
Due to the special evolving nature of anti-virus requirements and the complexity of maintaining security fixes for multiple releases, we will work to keep clamav current on all supported releases. See ClamavUpdates for details.
sun-java*
Ubuntu 9.04 and later include an officially tested and certified JDK called OpenJDK. Prior to Ubuntu 9.04, the only officially tested and certified JDKs were sun-java5 and sun-java6. These are binary-only packages shipped in multiverse.
To support users of 8.04 LTS who do not have access to the free OpenJDK, new upstream microreleases of sun-java5 and sun-java6 can be provided in -updates without checking individual changes for above SRU criteria for as long as Sun as provides updates. Verification just needs to prove that the packages still upgrade/install for users, and that Java applications and browser applets still run, using the packages from hardy-proposed.
Other users are recommended to upgrade to at least 9.04 and use the supported OpenJDK.
When upstream discontinues maintenance for a version of a sun-java* package (e.g. sun-java5), no more updates will be provided for that package. An announcement should be made to the ubuntu-devel-announce mailing list regarding the discontinued support of the affected package.
Examples
As a reference, see bug #173082 for an idea of how the SRU process works for a main package, or bug #208666 for an SRU in universe.
Links
Note that ubuntu-sru's subscribed bugs page may not be sufficient to catch bugs that (a) are Fix Released in the current development release and (b) have been nominated but not approved for stable releases. See the following links:
Useful links for motu-sru
StableReleaseUpdates (last edited 2024-11-12 14:14:03 by racb)