StableReleaseUpdates

Differences between revisions 82 and 83
⇤ ← Revision 82 as of 2008-01-31 15:41:17 →
Size: 12011
Editor: p57AAAFBF
Comment: add hw enablement for LTS
← Revision 83 as of 2008-02-29 16:15:15 → ⇥
Size: 8542
Editor: pd956a57b
Comment: much simplified description of procedure, split uploader/reviewer duties
Deletions are marked like this. Additions are marked like this.
Line 19: Line 19:
 * Bugs which may, under realistic circumstances, directly cause a '''security vulnerability'''  * Bugs which may, under realistic circumstances, directly cause a '''security vulnerability'''. These are done by the security team and are documented at SecurityUpdateProcedures.
Line 26: Line 26:
== How == == Procedure ==
Line 28: Line 28:
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.  1. Check that the bug is fixed in the current development release, and its bug report task is "Fix released".
Line 30: Line 30:
 1. Propose
 
  All proposals for stable release updates must be '''approved''' by a member of the [https://launchpad.net/~ubuntu-sru Stable Release Updates team] ( or the [https://launchpad.net/~motu-sru MOTU SRU Team] for Universe and Multiverse updates ). Attach all of the information to the existing bug report, use ''Nominate for release'' to mark the bug for backporting, then subscribe the `ubuntu-sru` team or `motu-sru` team depending on the component. If more than one bug is being addressed, each bug must be handled, justified, approved separately, and uploads will only be approved if all involved bugs are. SRU proposals ''must'' be accompanied by the following information for each bug to be addressed:		  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 34: Line 32:
   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; generally, SRUs will not be accepted if the bug has not been fixed in the development branch.
   1. 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. The patch must be as small and unintrusive as possible.
   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. These need to be put into the '''description''' of the bug (not just another comment), after a line which contains "{{{TEST CASE:}}}".
   1. A '''discussion''' of the regression potential of the patch and how users could get inadvertedly effected.		  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 inadvertedly effected.
Line 40: Line 39:
  The bug tasks need to accurately reflect the state in all releases and the proposed SRU targets. This makes it much easier for the SRU team to assess the state of the bug without having to wade through a long discussion in the bug's history.  1. Upload the fixed package to ''release''`-proposed` with the patch in the bug report, a detailled and user-readable changelog, and no other unrelated changes.
Line 42: Line 41:
  If applicable, consider whether the update should also be applied to any active LTS releases.  1. 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.
Line 44: Line 43:
 1. Prepare  1. Add yourself as a '''bug contact''' for the package in Launchpad, if you are not one already, and '''monitor Launchpad''' for bug reports relating to the update for at least one week.
Line 46: Line 45:
  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:  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. 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.
Line 48: Line 47:
   1. The changelog entry and resulting .changes file must include a reference to the corresponding '''bug report(s)'''
   1. The bug report must include an '''approved SRU proposal'''
   1. The '''version number(s)''' must be carefully checked in order to avoid clashing with any other version of the package, past, present or future
   1. The upload target must be ''release''`-proposed`
   1. The package difference must be a minimal change to fix the bug. For exceptions to this, see /MicroReleaseExceptions. Spurious changes to build systems, documentation, functionality ''will be rejected''.
   1. Make sure to generate the `.changes` file against the current version in `-proposed` or in `-updates`, using the `-v` option to `dpkg-buildpackage` or `debuild`.
   1. As with any upload, the changelog entry must properly credit the author of the change, if it was not originally made by you.		 == Verification ==
Line 56: Line 49:
  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. 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 inadvertant side effects.
Line 58: Line 51:
  Usually it is fine to upload the package, so that it is readily available for review for the SRU team. However, if you have doubts if your change is appropriate, please wait for the approval in the bug trail before upload. Inappropriate uploads will be rejected and commented on in the bug. Uploads with no or an invalid bug number in the changelog will be rejected. If they discover that your fix is insufficient, or the test case is not sufficient to reproduce the bug, they will:
Line 60: Line 53:
 1. Upload  1. Set the bug report '''Status: In Progress'''
 1. Describe why the fix was rejected in a comment to the bug report.
 1. Remove the `verification-needed tag`.
Line 62: Line 57:
  The upload will be reviewed by the SRU 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 SRU verification team may also discover that your fix is good. They will:
Line 64: Line 59:
  The `ubuntu-archive` team member who accepts the package into `-proposed` should:
   1. Add a `verification-needed` tag to the bug report.
   1. Set the bug report to '''Status: Fix Committed'''.
   1. Subscribe the `sru-verification` team.		  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.
Line 69: Line 62:
 1. Test

  Once the update has been published in `-proposed`, it can be tested by a wider audience.

   1. Test the package yourself
   1. If the update has the potential for hardware-specific effects, request a hardware support regression test in the bug report (for example, kernel updates); in this case, at least two users with the affected hardware must give positive test results in the bug report. The [https://launchpad.net/~sru-verification SRU verification team] will test the updated package on different hardware to check for inadvertant side effects.

  The [https://launchpad.net/~sru-verification SRU verification team] will regularly check open bugs with the `verification-needed` tag. If they discover that your fix is insufficient, 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. Remove the `verification-needed tag`.

  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.

 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 SRU verification team, the `ubuntu-archive` team member who accepts the package into `-updates` should:
   1. Copy the source and binary packages from `-proposed` to `-updates`.
   1. Set the bug report to '''Status: Fix Released'''.
   1. Remove the proposed package from `-proposed` (subject to [https://bugs.launchpad.net/soyuz/+bug/56037 bug 56037]).

 1. Follow up

  1. Add yourself as a '''bug contact''' for the package in Launchpad, if you are not one already
  1. For 7 days after the update is released, '''monitor Launchpad''' for bug reports relating to the update
  1. 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. ( NOTE: for MOTU-SRU's contact the [mailto:ubuntu-motu@lists.ubuntu.com Universe SRU Team] team or ask for help on `#ubuntu-motu` )		 If the update is hardware specific, at least two users with the affected hardware must give positive test results in the bug report.
Line 102: Line 66:

=== New micro releases ===

For some packages it is acceptable to upload new upstream micoreleases to stable Ubuntu releases. See /MicroReleaseExceptions for details.

Once an Ubuntu release has been completed and published, updates for it are only released under certain circumstances, and must follow a special procedure.

There is an automatically generated list of [http://people.ubuntu.com/~ubuntu-archive/pending-sru.html packages which currently undergo 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.

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 SecurityUpdateProcedures.

  • Bugs which represent severe regressions from the previous release of Ubuntu

  • 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.

  • NOTE: For Universe and Multiverse SRU's FTBFS, not installable, and segfault on startup ( e.g. completely un-usable ) can also be considered.

Procedure

  1. Check that the bug is fixed in the current development release, and its bug report task is "Fix released".

  2. 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.

  3. 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

    2. 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.

    3. 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.

    4. 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:".

    5. A discussion of the regression potential of the patch and how users could get inadvertedly effected.

  4. Upload the fixed package to release-proposed with the patch in the bug report, a detailled and user-readable changelog, and no other unrelated changes.

  5. 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.

  6. Add yourself as a bug contact for the package in Launchpad, if you are not one 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 [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. 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.

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 inadvertant side effects.

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

  2. Describe why the fix was rejected in a comment to the bug report.

  3. Remove the verification-needed tag.

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.

  2. Describe the general steps taken to verify the package, any special difficulties, and the recommended upload date.

If the update is hardware specific, at least two users with the affected hardware must give positive test results in the bug report.

Anchor(Special)

Special Cases

New micro releases

For some packages it is acceptable to upload new upstream micoreleases 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 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 a debdiff and other relevant information as above, and testing must still be recorded in the bug report.

(This section is based on discussions between MichaelVogt and ColinWatson)

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.

Examples

As a reference, see [https://launchpad.net/ubuntu/+source/cpio/+bug/59228 bug #59228] for an idea of how the SRU process works.

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:

CategoryProcess

StableReleaseUpdates (last edited 2025-06-25 19:59:52 by ahasenack)