Did you notice a regression in a package which went to -updates? Please report this using these steps.

1. Why

In contrast to pre-release versions, official releases of Ubuntu are subject to much wider use, and by a different demographic of users. 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.

In bug 559822, a C++ library (wxwidgets2.8) was uploaded with no code changes. Due to an underlying toolchain change/bug, this caused an ABI change, causing a lot of unrelated packages to break (see bug 610975)

We never assume that any change, no matter how obvious, is completely free of regression risk.

In line with this, the requirements for stable updates are not necessarily the same as those in the development release. When preparing future releases, one of our goals is to construct the most elegant and maintainable system possible, and this often involves fundamental improvements to the system's architecture, rearranging packages to avoid bundled copies of other software so that we only have to maintain it in one place, and so on. However, once we have completed a release, the priority is normally to minimise risk caused by changes not explicitly required to fix qualifying bugs, and this tends to be well-correlated with minimising the size of those changes. As such, the same bug may need to be fixed in different ways in stable and development releases.

2. When

2.1. High-impact bugs

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

Updates that need to be applied to Ubuntu packages to adjust to changes in the environment, server protocols, web services, and similar, i. e. where the current version just ceases to work. Examples:

app-install-data-commercial is a package index which regularly needs to be adjusted to changes in the commercial package archive.

A library for a web service needs to be updated for changes to the web server API.

2.2. Other safe cases

In the following cases a stable release update is also applicable as they have a low potential for regressing existing installations but a high potential for improving the user experience, particularly for Long Term Support releases:

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 not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers. This also includes updating hardware description data such as udev's keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates.

For Long Term Support releases we sometimes want to introduce new features. They must not change the behaviour on existing installations (e. g. entirely new packages are usually fine). If existing software needs to be modified to make use of the new feature, it must be demonstrated that these changes are unintrusive, have a minimal regression potential, and have been tested properly. To avoid regressions on upgrade, any such feature must then also be added to any newer supported Ubuntu release. Once a new feature/package has been introduced, subsequent changes to it are subject to the usual requirements of SRUs to avoid regressions.

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.

2.3. New upstream microreleases

In some cases, when upstream fixes bugs, they do a new microrelease instead of just sending patches. If all of the changes are appropriate for an SRU by the criteria above, then it is acceptable (and usually easier) to just upload the complete new upstream microrelease instead of backporting the individual patches. Note that some noise introduced by autoreconf is okay, but making structural changes to the build system (such as introducing new library dependencies) is generally not.

For upstreams who have

a reliable and credible test suite for assuring the quality of every commit or release,

the tests are covering both functionality and API/ABI stability,

the tests run during package build to cover all architectures,

the package has an autopkgtest to run the tests in an Ubuntu environment against the actual binary packages,

it is also acceptable to upload new microreleases with many bug fixes without individual Launchpad bugs for each of them (~ubuntu-sru will make the final decision). The upstream QA process must be documented/demonstrated and linked from the SRU tracking bug. In other cases where such upstream automatic testing is not available, exceptions must still be approved by at least one member of the Ubuntu Technical Board.

3. Procedure

Check that the bug is fixed in the current development release, and that its bug task is "Fix Released". Equivalently for new upstream releases, this (or a newer) release must be in the development release. It is, in general, not appropriate to release updates for stable systems without first testing them in the current development branch. One exception to this general rule is the case where the development release is not yet open, there can sometimes be a delay between the release of the most recent version of Ubuntu and the opening for development of the next version. Provided they are important enough, stable release updates should not and do not need to wait for the development release to open.

Also keep in mind that certain packages can change source package names between releases. In that case, if the given bug applies to a different source package that replaced the old one in a later releases, this source package has to be added as 'Also affecting'. Make sure that the devel releases package has the bug fixed before proceeding.

Ensure that the bug report for this issue is public. If the bug has been reported privately and cannot be published, you must first create a separate public bug report in launchpad and copy over as much information as can be published.

Update the bug report description and make sure it contains the following information:

An explanation of the bug on users and justification for backporting the fix to the stable release. This may be preceded with an [Impact] header, but this is not required. In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug.

A [Test Case] section with 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.

A [Regression Potential] section with a discussion of how regressions are most likely to manifest, or may manifest even if it is unlikely, as a result of this change. It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what could happen in the event of a regression. In the case of new upstream releases, link to the upstream QA procedure/documentation. This both shows the SRU team that the risks have been considered, and provides guidance to testers of what to watch out for when testing for regressions in the SRU. If this section is None it is grounds for rejection, consider 1590321 which is an example of a simple fix with a legitimate Regression Potential.

Prepare the upload, attach a debdiff to the bug, and request sponsorship by subscribing 'ubuntu-sponsors' to the bug. The upload must have the correct release in the changelog header, a detailed and user-readable changelog, and no other unrelated changes. If you can upload to the archive directly, use dput as normal. There is no need to wait before uploading. After upload, the bug status should be changed to In Progress, once accepted into release-proposed, the status will be automatically changed to Fix Committed. Also, 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.)

There is a reference to the SRU bug number in the changelog, using the 'LP: #NNNNNN' convention. Only public bugs should be referenced in the changelog.

The ~ubuntu-sru team will review and accept your upload. You can then test the actual binaries in the Ubuntu archive yourself and follow up in the bug report regarding your verification of the bug. The SRU team will evaluate the testing feedback and they will move the package into -updates after it has passed a minimum aging period of 7 days.

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.

Any regression must always be documented in a bug report, which must be Importance: critical once the regression has been confirmed.

3.1. SRU Bug Template

[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* 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.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance

4. Publishing

The Stable Release Updates team regularly checks for SRUs that have succesfully completed verification (all bugs are marked verification-done-$RELEASE for the given release) and releases those to the -updates pocket. Having said that, if there is a priority SRU waiting in the unapproved queue for release to -proposed, or needing release to -updates, feel free to contact an SRU vanguard. Vanguards from the SRU team can be found in #ubuntu-release on the following schedule:

Day

SRU Team Member (IRC nick)

Monday

Adam Conrad (infinity), Łukasz Zemczak (sil2100)

Tuesday

Brian Murray (bdmurray), Chris Halse Rogers (RAOF)

Wednesday

Chris J Arges (arges), Robie Basak (rbasak)

Thursday

Łukasz Zemczak (sil2100)

Friday

Timo Aaltonen (tjaalton), Steve Langasek (vorlon - backup)

5. Phasing

Once an update is released to -updates, the update is then phased so that the update is gradually made available to expanding subsets of Ubuntu users. This process allows us to automatically monitor for regressions and halt the update process if any are found. Complete details about the process can be found in a blog post by Brian Murray.

The Phased-Update-Percentage is initially set to 10%, and a job is run (every 6 hours) that checks for regressions and if none are found the phased update percentage will be incremented by 10%. So an update will become fully phased after 54 hours or about 2 days. In the event that a regression is detected the Phased-Update-Precentage will be set to 0% thereby causing supported package managers not to install the update.

The progress of phased updates is visible in a report which is updated by the same job that does the phasing.

6. 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, so these bugs will generally be invalidated by the SRU team. Just prepare all fixed bugs as described above, and either

attach the complete patch/debdiff to one bug and point to it in the other bugs ("debdiff which fixes this is attached to bug #xxxxxx")

or

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.

7. Verification

The SRU verification team will regularly check open bugs with the verification-needed* tags 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 with other packages from *-proposed (except other packages built from the affected source package - they must be updated if generally installed) or *-backports. While not ideal it is also possible for the uploader of the fix to perform the verification of the package in *-proposed, however it must still be done in a software environment as close as is feasible to that which will exist after the package is copied to *-updates.

If they discover that your fix is insufficient, or the test case is not sufficient to reproduce the bug, they will:

Set the bug task to Status: In Progress

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

Modify the verification-needed-$RELEASE tag to a verification-failed-$RELEASE tag on the bug report where $RELEASE is the release name which you tested.

The SRU verification team may also discover that your fix is good. They will:

Modify the 'verification-needed-$RELEASE' tag to a 'verification-done-$RELEASE' tag on the bug report where $RELEASE is the release name of the upload you have tested e.g. verification-done-precise. The tag global verification-needed should be left on the bug until all release tasks have been verified.

Describe the general steps taken to verify the package, and any special difficulties.

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

Follow up on 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-$RELEASE tag on the corresponding SRU bug report where $RELEASE is the release name of the upload you tested.

There is a standing agenda item for the SRU & LTS meeting to make sure all stakeholders are able to raise issues as early as possible.

Ensure all critical and high importance bugs are verified in a timely manner. If not, the SRU QA Engineer will perform the testing.

The SRU QA Engineer will specifically ask at the SRU & LTS meeting if there are specific bugs that need verification that aren't being done by the bug reporter. If necessary, a QA team member will do the verification. If not able (e.g. lack of specific HW), will do more calls for testing and nag the bug reporter again.

If necessary, the QA team will set up separate SRU verification program, for big packages like eglibc, python, X.

8. Removal of updates

If a bug fixed by an update does not get any testing/verification feedback for 90 days an automated call for testing comment will be made on the bug report. In the event that there is still no testing after an additional 15 days, that's a total of 105 days without any testing, the Stable Release Managers will remove the package from -proposed and usually close the bug task as "Won't Fix", due to lack of interest. Removal will happen immediately if a package update in -proposed is found to introduce a nontrivial regression.

9. Regressions

If a package update introduces a regression which already made it through the verification process to -updates, please immediately file a bug report about the isue, and add the tag regression-update to the bug.

If the regression only applies to the package in -proposed, please follow up to the bug with a detailed explanation, and tag the bug with regression-proposed.

9.1. Testing for Regressions

To minimise the risk of regressions being introduced via a SRU, testing will be perform by Canonical on each proposed kernel.

Depth Regression testing will be performed by the Ubuntu Platform QA team on minimal set of HW that represents the different flavours of Ubuntu Editions and Architectures. This activity will focus on verifying that hw-independent regressions have not been introduced.

Breadth hardware testing will be performed by the HW Certification team on release-certified HW. The test will verify that the proposed kernel can be successfully installed on the latest (point) release, network access is functional, and no other functionality is missing that will enable Update Manager to work correctly.

10. Documentation for 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. Most exception approvals are now handled directly by the SRU team.

To obtain a new ongoing exception such as those documented below:

Draft a wiki page, like the ones below, outlining what you believe should be the exception.

Submit it to the SRU team for approval. This can be done to any individual member of the SRU team directly, or you can send it to ubuntu-release@lists.ubuntu.com for review.

10.1. Kernel

Because of the way updates to the kernel work, it will follow a slightly different process which is described on KernelTeam/KernelUpdates.

10.3. Juju

10.4. Snapd

The snapd source package may be uploaded according to the procedure documented in SnapdUpdates. Per Technical Board discussion regarding delegation of these decisions to the SRU team, this stable release exception has been approved by SteveLangasek for the SRU team as of 2016-05-12.

10.5. Snapcraft

Related to the preceding snapd exception, the snapcraft source package may be uploaded according to the procedure documented in SnapcraftUpdates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2016-05-16.

10.6. Ubuntu-image

Also related to snapd, the ubuntu-image package may be uploaded according to the procedure documented in UbuntuImageUpdates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2016-10-19.

10.7. Docker.io group

The source packages docker.io, containerd, and runc may be uploaded according to the procedure documented in DockerUpdates. Per Technical Board discussion regarding delegation of these decisions to the SRU team, this stable release exception has been approved by BrianMurray for the SRU team as of 2016-09-20.

10.8. gce-compute-image-packages

The source package gce-compute-image-packages may be uploaded according to the procedure documented in gce-compute-image-packages-Updates. Per Technical Board discussion regarding delegation of these decisions to the SRU team, this stable release exception has been approved by BrianMurray for the SRU team as of 2017-03-10.

10.9. curtin

The source package curtin may be uploaded according to the procedure documented in CurtinUpdates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2017-04-05.

10.10. walinuxagent

The source package walinuxagent may be uploaded according to the procedure documented in walinuxagentUpdates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2017-04-05.

10.11. GNOME

10.12. OpenStack

OpenStack packages can be updated according to the procedures documented in OpenStackUpdates, which includes a list of source packages covered by the MRE. This stable release exception has been approved by LukaszZemczak for the SRU team as of 2017-08-07.

10.13. Certbot

The Certbot family of packages can be updated according to the procedures documented in /Certbot. This stable release exception was discussed and subsequently revision 10 of that document was approved by RobieBasak for the SRU team on 2017-08-08.

10.14. cloud-init

The source package cloud-init may be uploaded according to the procedure documented in CloudinitUpdates. Per Technical Board discussion regarding delegation of these decisions to the SRU team, this stable release exception has been approved by BrianMurray for the SRU team as of 2017-10-06.

10.15. DPDK

The dpdk source package can be uploaded according to the procedures documented in DPDK for supported LTS releases of Ubuntu. This stable release exception has been approved by LukaszZemczak for the SRU team as of 2017-08-07.

10.16. ubuntu-release-upgrader and python-apt

The packages ubuntu-release-upgrader and python-apt both contain files with listings of Ubuntu mirrors. To facilitate upgrades to new releases ubuntu-release-upgrader should be updated (particularly for LTS release) so that the list of mirrors is accurate. With that in mind and given that it is just a text file with urls for mirrors it is okay to SRU only mirror changes for these packages without an SRU bug.

10.17. rax-nova-agent

The source package rax-nova-agent may be uploaded according to the procedure documented in rax-nova-agent-Updates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2017-08-15.

11. Data Packages Kept in Sync with Security

Some data packages must always be kept in sync between -updates and -security to avoid behaviour or functionality regressions when using only the security pocket. Because they are pure data, and contain no compiled code, these packages are safe to build in -proposed and then copy to both -updates and -security.

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

Because tzdata's packaging has changed subtly from release to release, rather than just backporting the most recent release's source package, we just update the upstream tarball instead. You then need to edit debian/changelog to add bug closures, and make sure to use a version number consistent to the previous numbering scheme (e. g. 2012e-0ubuntu0.12.04).

Due to the potentially disastrous consequences of having localtime differ between systems running -updates and systems running only -security, this package is always kept in sync between the two pockets.

11.2. distro-info-data

Many tools behave drastically differently based on the contents of ubuntu.csv in distro-info-data. As such, information for new releases is always backported to -updates, and should always be copied to -security to avoid behaviour skew between the two pockets.

11.3. linux-firmware

linux-firmware in stable releases is kept in sync with new driver features and lts-hwe kernel updates. linux-firmware follows the normal SRU process (with bugs filed and regression tests performed), however it must also be copied to the -security pocket once verified, due to the vast majority of kernel SRUs also being in the -security pocket, and the necessity of linux and linux-firmware not being mismatched.

11.4. wireless-regdb

Much like linux-firmware, wireless-regdb follows the usual SRU process, including a bug and regression testing, however it is another package that needs to be kept in sync between -updates and -security pockets to avoid potential local legal issues for -security users who would otherwise not get the local regdb updates.

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

13. Package Removals

While it is always preferable to fix a package, rather than drop it, there are rare cases when a universe package becomes actively detrimental in stable releases: If it is unmaintained in Ubuntu and has unfixed security issues or has been broken because of changing network protocols/APIs, it is better to stop offering it in Ubuntu altogether rather than continuing to encourage users to install it.

It is not technically possible to remove a package from a stable release, but this can be approximated by SRUing an essentially empty package with an appropriate explanation in NEWS and a corresponding critical debconf note.

When a package is removed in this way from a stable release, it may need similar removal from the devel release as well, depending on the justification for removal.

Such a package removal should have an SRU tracking bug with an appropriate explanation, and needs to get confirmed by the Technical Board. Once removed, the SRU bug should be added to the "Previous Removals" list below.

For each package, generate the debdiff to the current version in the archive and open the corresponding bugs:

sru-review -s saucy gnash

This opens all the bugs which are mentioned in the .changes file in the browser, and will generate a debdiff between the current archive and the unapproved upload (unless the orig.tar.gz changes this will only download the two diff.gz, so it is reasonably fast).

In case the SRU is a package sync instead of a standard upload, the sru-review tool will not be able to fetch the debdiff for you and will exit with an error. You will have to review the changes manually and then re-run the tool with an additional argument of --no-diff.

For Bileto published SRU's you can easily fetch the relevant debdiffs by following the link to the sync's source PPA and opening the ticket URL that's provided in the PPA description. Each upload present there has two diffs generated for review convenience: full and packaging-only.

Review the bugs for complete description, justification, check that they have a stable release task, are conformant to SRU rules, etc, and comment accordingly.

Scrutinize the debdiff for matching the changes in the bugs, not having unrelated changes, etc. If you have doubts, comment on the bug.

If you are in the ubuntu-sru team:

Exit the tool you are using to review the debdiff

If the bugs and debdiff are okay, accept the package by pressing y at the ""Accept the package into -proposed?" prompt.

This will tag the bug(s) with verification-needed, verification-needed-$RELEASE, subscribe ubuntu-sru, and add a general "please test and give feedback"-like comment.

If the upload is broken or unsuitable for an SRU, reject it by pressing N at the ""Accept the package into -proposed?" prompt and pressing y at the "REJECT the package from -proposed?" prompt.

If you are not in the ubuntu-sru team: Send a follow up comment to the bugs:

If all is okay: send an "ubuntu-sru approved and reviewed" comment and set the task to "In Progress"

If something is wrong: send the feedback to the bug and set the task to "Incomplete"

The pending SRUs should also be reviewed to see whether or not there are any to be released or removed from the archive. The process for dealing with these follows:

Packages in -proposed can be moved to -updates once they are approved by someone from sru-verification, and have passed the minimum aging period of 7 days. Use the sru-release script from ubuntu-archive-tools for this:

$ ./sru-release xenial kdebase

Please see --help, you can also use this tool to copy packages to -security and to the current development release. N.B. before copying a package to -security ping a member of the ubuntu-security team.