Draft

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

  • 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.
  • Bugs which do not fit under above categories, but:
    • have an obviously safe patch.
    • affect an application rather than critical infrastructure packages (like X.org or the kernel).

Also, bugs which may, under realistic circumstances, directly cause a security vulnerability. These are done by the security team and follow a different procedure, documented at SecurityUpdateProcedures.

Procedure

  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.

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

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

    • A discussion of the regression potential of the patch and how users could get inadvertently effected.

    • 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. You can use this template: 

      TEST CASE

PROCEDURE:
  Detailed steps to reproduce the bug
  
RESULT ON PASS:
  What should we expect if application worked correctly?

RESULT ON FAIL:
  What went wrong instead?

END TEST CASE

  4. Subscribe ubuntu-sru for packages in main/restricted, or motu-sru for packages in universe/multiverse and wait for a member to approve SRU candidate. Do not attempt to upload without a public acknowledgment, in case of urgency contact one of the members on IRC or by e-mail.

  5. Once approved, upload the fixed package to release-proposed. Be sure to follow these guidelines:

    • Provide a detailed and user-readable changelog. Always include LP bug numbers you are referring to.
    • Limit changes only to fix related bugs, do not include other unrelated changes.
    • Make sure that the version number does not conflict with any later and future version in other Ubuntu releases: 
      =====================  =======================================
''Actual version''     ''SRU version''
2.0-2                  2.0-2ubuntu0.1
2.0-2ubuntu2           2.0-2ubuntu2.1
2.0-2ubuntu2.1         2.0-2ubuntu2.2
2.0-2build1            2.0-2ubuntu0.1
2.0                    2.0-0ubuntu0.1
2.0-2 in two releases  2.0-2ubuntu0.8.04 and 2.0-2ubuntu0.7.10
=====================  =======================================

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

  7. Add yourself as a bug contact for the package in Launchpad 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, keescook, 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.

Verification

Developers, users and other interested parties can check open bugs with the verification-needed tag (or check the ones listed here) and test proposed updates on different hardware to check for inadvertent side effects.

If fix is insufficient, or the test case is not sufficient to reproduce the bug:

  1. Set the bug report Status: In Progress

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

  3. Remove the verification-needed tag.

If fix is good, and at least two positive and no negative testimonials stated so:

  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 and any special difficulties.

Please follow these guidelines when performing SRU verifications.

Special Cases

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 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)

Landscape

Note: This section was not approved by the Technical Board yet, and has not been exercised yet. This should be replaced by a more general formulation which applies to similar cases as well.

  • -- Landscape should be made available to users of 6.06 LTS and other supported releases for their entire lifetime, which will necessitate new feature releases. Being a client/server application, Landscape needs to maintain some level of synchronization between the client and server code, to minimize the number of different version interactions.

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 hal-updates.

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.

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/Draft (last edited 2008-08-06 17:00:52 by localhost)