Diff for "StableReleaseUpdates"

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.

Note that the SRU team's delegation from the Technical Board is limited to accepting SRU uploads that meet the policy criteria above. The SRU team maintains documentation for standing exceptions here to keep individual interpretations of the policy criteria consistent. Departing from the policy criteria above still requires approval from the Technical Board.

Kernel

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

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.

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.

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.

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.

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.

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. Further amendment to this exception for vendored dependencies approved by LukaszZemczak for the SRU team as of 2023-04-11.

google-compute-engine

The source package gce-compute-image-packages may be uploaded according to the procedure documented in google-compute-engine-Updates. 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 2022-09-01. Further amendment to this exception for vendored dependencies approved by LukaszZemczak for the SRU team as of 2023-04-11.

google-compute-engine-oslogin

The source package google-compute-engine-oslogin may be uploaded according to the procedure documented in google-compute-engine-oslogin-Updates. 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 2022-09-01. Further amendment to this exception for vendored dependencies approved by LukaszZemczak for the SRU team as of 2023-04-11.

google-guest-agent

The source package gce-compute-image-packages may be uploaded according to the procedure documented in google-guest-agent-Updates. 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 2022-09-01. Further amendment to this exception for vendored dependencies approved by LukaszZemczak for the SRU team as of 2023-04-11.

google-osconfig-agent

The source package google-osconfig-agent may be uploaded according to the procedure documented in google-osconfig-agent-Updates. 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 2022-09-01. Further amendment to this exception for vendored dependencies approved by LukaszZemczak for the SRU team as of 2023-04-11.

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.

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.

GNOME

GNOME has a microrelease exception excepting it from the normal QA requirements of the microrelease policy, documented here. This was granted by the technical board on 2012-06-22.

OpenStack

OpenStack packages can be updated according to the procedures documented in OpenStack/StableReleaseUpdates, 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.

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.

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 with subsequent updates approved by RobieBasak on 2020-07-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.

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

apt and python-apt

Not a policy exception, but see AptUpdates for details of unusual SRU versioning.

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 2018-08-15.

livecd-rootfs

The livecd-rootfs package is a frequent target of SRUs as part of development of changes to image builds for the target series, and is not intended for general installation on end-user systems. The risk of user-affecting regression is lower as a result, because the impact of changes to this package to end users is mediated by way of image builds. Therefore, the requirement for per-change bug reports and test cases is relaxed, as long as there is at least one linked bug with a test case.

fwupd and fwupdate

The source packages fwupd and fwupdate may be uploaded according to the procedure documented in firmware-updates. This stable release exception has been approved by BrianMurray for the SRU team as of 2019-01-15.

snapd-glib

The source package snapd-glib may be uploaded according to the procedure documented in snapd-glib updates. This stable release exception has been approved by BrianMurray for the SRU team as of 2019-02-19.

netplan.io

The source package netplan.io may be uploaded according to the procedure documented in netplan updates. This stable release exception has been approved by BrianMurray for the SRU team as of 2019-04-01 (no really!).

ec2-hibinit-agent

The source package ec2-hibinit-agent may be uploaded according to the procedure documented in ec2-hibinit-agent updates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2019-09-06.

NVIDIA driver

NVIDIA driver (source packages nvidia-graphics-drivers-*, nvidia-settings, fabric-manager-*, libnvidia-nscq-*) may be uploaded according to the procedure documented in NVIDIA updates. This stable release exception has been approved by ChrisHalseRogers for the SRU team as of 2019-09-17.

wslu

The wslu package may be uploaded according to the procedure documented in wslu Updates. This stable release exception has been approved by LukaszZemczak for the SRU team as of 2019-10-24.

openjdk-N

We allow providing OpenJDK short term support releases in the updates pocket, instead of the release pocket to be able to remove those after their support ends as documented in OpenJDK Updates. This very specific stable release exception has been approved by LukaszZemczak for the SRU team as of 2020-04-30.

Postfix

The postfix source package may be uploaded according to the procedure documented in PostfixUpdates. See the Technical Board meeting minutes and its approval for details and rationale.

sosreport

The source package sosreport may be uploaded according to the procedure documented in sosreport updates. This stable release exception has been approved by LukaszZemczak for the SRU team as of 2020-06-25.

oem-*-meta

Source packages of the form oem-*-meta may be uploaded according to the procedure documented in OEMMeta. This stable release exception has been approved by AndyWhitcroft for the SRU team as of 2021-07-15. New packages are acceptable under the same exception.

ubuntu-dev-tools

The source package ubuntu-dev-tools may be uploaded according to the procedure documented in UbuntuDevToolsUpdates. This stable release exception has been approved by Robie Basak.

OpenLDAP

The OpenLDAP source package may be uploaded according to the procedure documented in OpenLDAPUpdates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2022-06-02.

HAProxy

The haproxy source package may be uploaded according to the procedure documented in HAProxyUpdates. This stable release exception has been approved by LukaszZemczak for the SRU team as of 2022-06-27.

autopkgtest

The autopkgtest source package may be uploaded according to the procedure documented in autopkgtest-Updates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2023-01-30.

squid

The squid source package may be uploaded according to the procedure documented in SquidUpdates. This stable release exception has been approved by SteveLangasek for the SRU team on 2023-04-03.

bind9

The bind9 source package may be uploaded according to the procedure documented in Bind9Updates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2023-06-06.

virtualbox

*** THIS IS OUTDATED !!! *** The virtualbox source packages may be uploaded according to the procedure documented in VirtualboxUpdates. This stable release exception has been approved by Martin Pitt for the SRU team as of 2015-11-04.

ubuntu-advantage-tools

The ubuntu-advantage-tools source package may be uploaded according to the SRU procedures documented in UbuntuAdvantageToolsUpdates. This stable release exception has been approved by RobieBasak for the SRU team part as of 2023-10-04.

open-vm-tools

The open-vm-tools source package may be uploaded according to the proceedure documented in OpenVMToolsUpdates. This stable release exception has been approved by ChrisHalseRogers for the SRU team as of 2024-01-25.

postgresql

The currently supported postgresql source package (as determined by the dependency of the postgresql metapackage) for each stable release may be uploaded according to the proceedure documented in PostgreSQLUpdates. This stable release exception has been approved by ChrisHalseRogers for the SRU team as of 2024-01-31

GRUB

GRUB related packages require a special SRU process due our EFI signing pipeline, documented at StableReleaseUpdates/Grub.

OpenVPN

Updates including upstream OpenVPN microreleases should follow the special case documentation at OpenVPNUpdates. This is not a standing approval or policy exception, but a general pattern to update OpenVPN upstream microreleases consistently under existing SRU policy.

Language Packs (language-pack-*)

There is some documentation at: https://git.launchpad.net/langpack-o-matic/tree/doc/operator-guide.txt

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.

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" (you can find the region and timezone name by grep'ing for it in /usr/share/zoneinfo/). This is compared to the same output after the updated package was installed. If those are different the verification is considered done.

Feature	16.04 LTS	18.04 LTS	20.04 LTS	21.04	21.10
icu-data	No	No	Yes	Yes	Yes
SystemV tzs	Yes	Yes	Yes	No	No

The version of tzdata in Ubuntu 20.04 LTS and later includes icu-data (see the update-icu rule in debian/rules) and the verification of it can be done after installing the python3-icu package. There can be a slight lag between the tzdata release and the matching icu-data release, we usually wait for the latter to be released before uploading the update.

python3 -c "from datetime import datetime; from icu import ICUtzinfo, TimeZone; tz = ICUtzinfo(TimeZone.createTimeZone('Pacific/Fiji')); print(str(tz.utcoffset(datetime(2020, 11, 10))))"

In the above we are checking a timezone with a change, "Pacific/Fiji", and a date that falls with in the changing period. We expect the output to be different before (13:00:00) and after (12:00:00) the SRU is installed.

The version of tzdata in Ubuntu 20.10 removed supported for SystemV timezones, however SRUs of tzdata to Ubuntu 20.04 LTS and earlier releases should still include the SystemV timezones. To test that they are still available confirm the following command returns nothing.

diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | cut -d' ' -f2-)

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). Uploads should also be made to any releases supported via ESM.

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. However, the package can be built with -updates and then copied from -proposed to -updates and -security after the security team has signed off on the SRU bug e.g. 1878108.

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.

This package should be updated as soon as possible after the new release's name is known. If only the adjective is known, it should be updated even with this partial information (use XANIMAL for the animal where X is the first letter of the adjective). The aging requirement is not applied for releasing to -updates / -security. A tracking bug is still required for SRUs. Verification is still required. The testing section should contain:

[ Test Plan ]
  
Verify that the following subcommands of `distro-info` print information about the new devel and current stable releases:
  
 * `--devel`
 * `--supported`
 * `--stable`

and try the same commands with these modifiers:

 * `--date=<1 day after release>` along with the above
 * `--fullname`
 * `--release`

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.

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.

Toolchain Updates

Due to the nature of the various Ubuntu toolchain packages (gcc-*, binutils, glibc), any stable release updates of these packages should be released to both the -updates and -security pockets. For that to be possible, any updates of those should be first built in a reliable security-enabled PPA (without -updates or -proposed enabled) and only then binary-copied into -proposed for testing (that is a hard-requirement for anything copied into -security). After the usual successful SRU verification and aging, the updated packages should be released into both pockets.

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.

Package Removals

This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/non-standard-processes/#explanation-removals

Links

This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/status/

Reviewing procedure and tools

This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/internal/#reviewing-procedure-and-tools

Contacting the SRU team

This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/contact/

CategoryProcess

StableReleaseUpdates (last edited 2024-11-12 14:14:03 by racb)

-  ⇤ ← Revision 122 as of 2008-12-12 18:37:02 → 
  Size: 12799
  Editor: 216
  Comment: best link
+   ← Revision 393 as of 2024-11-12 14:14:03 → ⇥
  Size: 27936
  Editor: racb
  Comment: Link to language pack documentation
-Deletions are marked like this.
+Additions are marked like this.
 Line 3:
-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]].
+{{{#!wiki warning
SRU documentation has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/

See the announcement: https://lists.ubuntu.com/archives/ubuntu-devel/2024-August/043090.html

Apart from the #Documentation_for_Special_Cases section below, this page is retained to redirect readers to the new documentation only.
}}}
-Line 9:
+Line 13:
-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.
+{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/principles/ and https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/requirements/
}}}
-Line 17:
+Line 19:
-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. 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 [[https://help.ubuntu.com/community/UbuntuBackports|backport]] should be requested instead.
+{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#what-is-acceptable-to-sru
}}}

=== High-impact bugs ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#what-is-acceptable-to-sru

=== Other safe cases ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#other-safe-cases

=== New upstream microreleases ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#new-upstream-microreleases

=== Staging low priority uploads ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/non-standard-processes/#explanation-staged-uploads

=== ESM Uploads ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/special/

<<Anchor(GeneralRequirements)>>
== General Requirements ==

{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#general-requirements-for-all-srus
}}}

=== Development Release Fixed First ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#general-requirements-for-all-srus

=== Newer Releases ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#general-requirements-for-all-srus
-Line 31:
+Line 60:
-. 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.

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

 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.

 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 [[SecurityUpdateProcedures#Prepare|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.

 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 are not one already, and '''monitor Launchpad''' for bug reports relating to the update for at least one week.
+{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/standard/
}}}

=== SRU Bug Template ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/bug-template/

=== Bug references in changelogs ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#bug-references-in-changelogs

=== Staging an upload ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/special/#stage-an-upload

==== Landing an upload blocked by staging ====

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/special/#land-an-upload-blocked-by-staging

==== Responsibility for SRU verification and cancellation of incomplete verification ====

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/non-standard-processes/#explanation-staged-uploads

== Publishing ==

{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/release/
}}}

== Phasing ==

{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/standard-processes/#phasing
}}}

=== Investigation of Halted Phased Updates ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/phasing/

=== SRU team documentation ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/internal/#override-phasing

== Verification ==

{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/standard/ and https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/regression/#howto-report-regression
}}}

=== Autopkgtest Regressions ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/autopkgtest-failure/

==== Expected resolution for reported autopkgtest failures ====

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/autopkgtest-failure/

== Removal of updates ==

{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/non-standard-processes/#removal-of-languishing-updates
}}}

== Regressions ==
-Line 49:
+Line 126:
- 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).
+{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/regression/#howto-report-regression
}}}

=== Testing for Regressions ===

(defunct section removed)
-Line 81:
+Line 136:
-== Special Cases ==

=== New micro releases ===

For some packages it is acceptable to upload new upstream microreleases to stable Ubuntu releases. See /MicroReleaseExceptions for details.
+== Documentation for 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. Most exception approvals are now handled directly by the SRU team.

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

 1. Draft a wiki page, like the ones below, outlining what you believe should be the exception.
 2. 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.

Note that the SRU team's delegation from the Technical Board is limited to accepting SRU uploads that meet the [[#When|policy criteria]] above. The SRU team maintains documentation for standing exceptions here to keep individual interpretations of the policy criteria consistent. Departing from the policy criteria above still requires approval from the Technical Board.
-Line 89:
+Line 149:
-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 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)
+Because of the way updates to the kernel work, it will follow a slightly
different process which is described on KernelTeam/KernelUpdates.
-Line 99:
+Line 154:
-''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.''
+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.

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

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

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

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

=== gce-compute-image-packages ===
The source package gce-compute-image-packages may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/gce-compute-image-packages-Updates|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. Further amendment to this exception for vendored dependencies approved by LukaszZemczak for the [[https://lists.ubuntu.com/archives/ubuntu-release/2023-April/005606.html|SRU team as of 2023-04-11]].

=== google-compute-engine ===
The source package gce-compute-image-packages may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/google-compute-engine-Updates|google-compute-engine-Updates]].  Per Technical Board discussion regarding delegation of these decisions to the SRU team, this stable release exception has been approved by SteveLangasek for the [[https://lists.ubuntu.com/archives/ubuntu-release/2022-September/005479.html|SRU team as of 2022-09-01]]. Further amendment to this exception for vendored dependencies approved by LukaszZemczak for the [[https://lists.ubuntu.com/archives/ubuntu-release/2023-April/005606.html|SRU team as of 2023-04-11]].

=== google-compute-engine-oslogin ===
The source package google-compute-engine-oslogin may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/google-compute-engine-oslogin-Updates|google-compute-engine-oslogin-Updates]].  Per Technical Board discussion regarding delegation of these decisions to the SRU team, this stable release exception has been approved by SteveLangasek for the [[https://lists.ubuntu.com/archives/ubuntu-release/2022-September/005479.html|SRU team as of 2022-09-01]]. Further amendment to this exception for vendored dependencies approved by LukaszZemczak for the [[https://lists.ubuntu.com/archives/ubuntu-release/2023-April/005606.html|SRU team as of 2023-04-11]].

=== google-guest-agent ===
The source package gce-compute-image-packages may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/google-guest-agent-Updates|google-guest-agent-Updates]].  Per Technical Board discussion regarding delegation of these decisions to the SRU team, this stable release exception has been approved by SteveLangasek for the [[https://lists.ubuntu.com/archives/ubuntu-release/2022-September/005479.html|SRU team as of 2022-09-01]]. Further amendment to this exception for vendored dependencies approved by LukaszZemczak for the [[https://lists.ubuntu.com/archives/ubuntu-release/2023-April/005606.html|SRU team as of 2023-04-11]].

=== google-osconfig-agent ===
The source package google-osconfig-agent may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/google-osconfig-agent-Updates|google-osconfig-agent-Updates]].  Per Technical Board discussion regarding delegation of these decisions to the SRU team, this stable release exception has been approved by SteveLangasek for the [[https://lists.ubuntu.com/archives/ubuntu-release/2022-September/005479.html|SRU team as of 2022-09-01]]. Further amendment to this exception for vendored dependencies approved by LukaszZemczak for the [[https://lists.ubuntu.com/archives/ubuntu-release/2023-April/005606.html|SRU team as of 2023-04-11]].

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

=== walinuxagent ===
The source package walinuxagent may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/walinuxagentUpdates|walinuxagentUpdates]].  This stable release exception has been approved by SteveLangasek for the SRU team as of 2017-04-05.

=== GNOME ===

GNOME has a microrelease exception excepting it from the normal QA requirements of the microrelease policy, [[/GNOME|documented here]]. This was [[https://lists.ubuntu.com/archives/technical-board/2012-June/001327.html|granted by the technical board on 2012-06-22]].

=== OpenStack ===

!OpenStack packages can be updated according to the procedures documented in OpenStack/StableReleaseUpdates, 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.

=== Certbot ===

The Certbot family of packages can be updated according to the procedures documented in [[/Certbot]]. This stable release exception was [[https://lists.ubuntu.com/archives/ubuntu-release/2017-July/004176.html|discussed]] and subsequently revision 10 of that document was approved by RobieBasak for the SRU team on 2017-08-08.

=== 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 with subsequent updates approved by RobieBasak on 2020-07-15.

=== DPDK ===

The dpdk source package can be uploaded according to the procedures documented in [[StableReleaseUpdates/DPDK|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.

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

=== apt and python-apt ===

Not a policy exception, but see AptUpdates for details of unusual SRU versioning.

=== rax-nova-agent ===
The source package rax-nova-agent may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/rax-nova-agent-Updates|rax-nova-agent-Updates]].  This stable release exception has been approved by SteveLangasek for the SRU team as of 2018-08-15.

=== livecd-rootfs ===
The livecd-rootfs package is a frequent target of SRUs as part of development of changes to image builds for the target series, and is not intended for general installation on end-user systems.  The risk of user-affecting regression is lower as a result, because the impact of changes to this package to end users is mediated by way of image builds.  Therefore, the requirement for per-change bug reports and test cases is relaxed, as long as there is at least one linked bug with a test case.

=== fwupd and fwupdate ===
The source packages fwupd and fwupdate may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/firmware-updates|firmware-updates]]. This stable release exception has been approved by BrianMurray for the SRU team as of 2019-01-15.

=== snapd-glib ===
The source package snapd-glib may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/SnapdGlibUpdates|snapd-glib updates]]. This stable release exception has been approved by BrianMurray for the SRU team as of 2019-02-19.

=== netplan.io ===
The source package netplan.io may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/NetplanUpdates|netplan updates]]. This stable release exception has been approved by BrianMurray for the SRU team as of 2019-04-01 (no really!).

=== ec2-hibinit-agent ===
The source package ec2-hibinit-agent may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/ec2-hibinit-agent-Updates|ec2-hibinit-agent updates]].  This stable release exception has been approved by SteveLangasek for the SRU team as of 2019-09-06.

=== NVIDIA driver ===
NVIDIA driver (source packages nvidia-graphics-drivers-*, nvidia-settings, fabric-manager-*, libnvidia-nscq-*) may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/NVidiaUpdates|NVIDIA updates]]. This stable release exception has been approved by ChrisHalseRogers for the SRU team as of 2019-09-17. 

=== wslu ===
The wslu package may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/wslu-Updates|wslu Updates]]. This stable release exception has been approved by LukaszZemczak for the SRU team as of 2019-10-24.

=== openjdk-N ===

We allow providing OpenJDK short term support releases in the updates pocket, instead of the release pocket to be able to remove those after their support ends as documented in [[https://wiki.ubuntu.com/OpenJDK-Updates|OpenJDK Updates]]. This very specific stable release exception has been approved by LukaszZemczak for the SRU team as of 2020-04-30.

=== Postfix ===

The postfix source package may be uploaded according to the procedure documented in PostfixUpdates. See the [[https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-October/000902.html|Technical Board meeting minutes]] and its [[https://lists.ubuntu.com/archives/technical-board/2012-May/001266.html|approval]] for details and rationale.

=== sosreport ===
The source package sosreport may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/SosreportUpdates|sosreport updates]]. This stable release exception has been approved by LukaszZemczak for the SRU team as of 2020-06-25.

=== oem-*-meta ===
Source packages of the form oem-*-meta may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/StableReleaseUpdates/OEMMeta|OEMMeta]]. This stable release exception has been approved by AndyWhitcroft for the SRU team as of 2021-07-15.  New packages are acceptable under the same exception.

=== ubuntu-dev-tools ===
The source package ubuntu-dev-tools may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/UbuntuDevToolsUpdates|UbuntuDevToolsUpdates]]. This stable release exception has been [[https://lists.ubuntu.com/archives/ubuntu-release/2023-May/005640.html|approved by Robie Basak]].

=== OpenLDAP ===

The OpenLDAP source package may be uploaded according to the procedure documented in [[OpenLDAPUpdates]]. This stable release exception [[https://lists.ubuntu.com/archives/ubuntu-release/2022-June/005403.html|has been approved]] by SteveLangasek for the SRU team as of 2022-06-02.

=== HAProxy ===

The haproxy source package may be uploaded according to the procedure documented in [[HAProxyUpdates]]. This stable release exception [[https://lists.ubuntu.com/archives/ubuntu-release/2022-June/005417.html|has been approved]] by LukaszZemczak for the SRU team as of 2022-06-27.

=== autopkgtest ===

The autopkgtest source package may be uploaded according to the procedure documented in [[autopkgtest-Updates]]. This stable release exception [[https://lists.ubuntu.com/archives/ubuntu-release/2023-January/005530.html|has been approved]] by SteveLangasek for the SRU team as of 2023-01-30.

=== squid ===
The squid source package may be uploaded according to the procedure documented in [[SquidUpdates]].  This stable release exception [[https://lists.ubuntu.com/archives/ubuntu-release/2023-April/005589.html|has been approved]] by SteveLangasek for the SRU team on 2023-04-03.

=== bind9 ===

The bind9 source package may be uploaded according to the procedure documented in [[Bind9Updates]]. This stable release exception [[https://lists.ubuntu.com/archives/ubuntu-release/2023-June/005647.html|has been approved]] by SteveLangasek for the SRU team as of 2023-06-06.

=== virtualbox ===

*** THIS IS OUTDATED !!! ***
The virtualbox source packages may be uploaded according to the procedure documented in [[https://wiki.ubuntu.com/VirtualboxUpdates|VirtualboxUpdates]]. This stable release exception [[https://lists.ubuntu.com/archives/technical-board/2015-November/002177.html|has been approved]] by Martin Pitt for the SRU team as of 2015-11-04.

=== ubuntu-advantage-tools ===

The ubuntu-advantage-tools source package may be uploaded according to the SRU procedures documented in [[UbuntuAdvantageToolsUpdates]]. This stable release exception [[https://lists.ubuntu.com/archives/ubuntu-release/2023-October/005810.html|has been approved]] by RobieBasak for the SRU team part as of 2023-10-04.

=== open-vm-tools ===

The open-vm-tools source package may be uploaded according to the proceedure documented in [[OpenVMToolsUpdates]]. This stable release exception [[https://lists.ubuntu.com/archives/ubuntu-release/2024-January/005900.html|has been approved]] by ChrisHalseRogers for the SRU team as of 2024-01-25.

=== postgresql ===

The currently supported postgresql source package (as determined by the dependency of the postgresql metapackage) for each stable release may be uploaded according to the proceedure documented in [[PostgreSQLUpdates]]. This stable release exception [[https://lists.ubuntu.com/archives/ubuntu-release/2024-January/005915.html|has been approved]] by ChrisHalseRogers for the SRU team as of 2024-01-31

=== GRUB ===

GRUB related packages require a special SRU process due our EFI signing pipeline, documented at [[StableReleaseUpdates/Grub]].

=== OpenVPN ===

Updates including upstream OpenVPN microreleases should follow the special case documentation at [[OpenVPNUpdates]]. This is not a standing approval or policy exception, but a general pattern to update OpenVPN upstream microreleases consistently under existing SRU policy.

=== Language Packs (language-pack-*) ===

There is some documentation at: https://git.launchpad.net/langpack-o-matic/tree/doc/operator-guide.txt

<<Anchor(Security)>>
== 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.
-Line 107:
+Line 312:
-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.
+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" (you can find the region and timezone name by grep'ing for it in /usr/share/zoneinfo/). This is compared to the same output after the updated package was installed. If those are different the verification is considered done.

||'''Feature'''||'''16.04 LTS'''||'''18.04 LTS'''||'''20.04 LTS'''||'''21.04'''||'''21.10'''||
||icu-data     || No            || No            || Yes           || Yes       || Yes       ||
||SystemV tzs  || Yes           || Yes           || Yes           || No        || No        ||

The version of tzdata in Ubuntu 20.04 LTS and later includes icu-data (see the update-icu rule in debian/rules) and the verification of it can be done after installing the '''python3-icu''' package. There can be a slight lag between the tzdata release and the matching icu-data release, we usually wait for the latter to be released before uploading the update.

{{{
python3 -c "from datetime import datetime; from icu import ICUtzinfo, TimeZone; tz = ICUtzinfo(TimeZone.createTimeZone('Pacific/Fiji')); print(str(tz.utcoffset(datetime(2020, 11, 10))))"
}}}

In the above we are checking a timezone with a change, "Pacific/Fiji", and a date that falls with in the changing period. We expect the output to be different before (13:00:00) and after (12:00:00) the SRU is installed.

The version of tzdata in Ubuntu 20.10 removed supported for SystemV timezones, however SRUs of tzdata to Ubuntu 20.04 LTS and earlier releases should still include the SystemV timezones. To test that they are still available confirm the following command returns nothing.

{{{
diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | cut -d' ' -f2-)
}}}

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`). Uploads should also be made to any releases supported via ESM.

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. However, the package can be built with -updates and then copied from -proposed to -updates and -security after the security team has signed off on the SRU bug e.g. Bug:1878108.

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

This package should be updated as soon as possible after the new release's name is known. If only the adjective is known, it should be updated even with this partial information (use XANIMAL for the animal where X is the first letter of the adjective). The aging requirement is not applied for releasing to -updates / -security. A tracking bug is still required for SRUs. Verification is still required. The testing section should contain:

{{{
[ Test Plan ]
  
Verify that the following subcommands of `distro-info` print information about the new devel and current stable releases:
  
 * `--devel`
 * `--supported`
 * `--stable`

and try the same commands with these modifiers:

 * `--date=<1 day after release>` along with the above
 * `--fullname`
 * `--release`
}}}

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

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

=== Toolchain Updates ===

Due to the nature of the various Ubuntu toolchain packages (gcc-*, binutils, glibc), any stable release updates of these packages should be released to both the -updates and -security pockets. For that to be possible, any updates of those should be first built in a reliable security-enabled PPA (without -updates or -proposed enabled) and only then '''binary-copied''' into -proposed for testing (that is a hard-requirement for anything copied into -security). After the usual successful SRU verification and aging, the updated packages should be released into both pockets.
-Line 128:
+Line 374:
+== Package Removals ==

{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/non-standard-processes/#explanation-removals
}}}
-Line 130:
+Line 382:
-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/gutsy/+nominations?field.subscriber=ubuntu-sru|Gutsy]]
 * [[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]]

=== 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]]
+{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/status/
}}}

== Reviewing procedure and tools ==

{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/internal/#reviewing-procedure-and-tools
}}}

== Contacting the SRU team ==

{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/contact/
}}}

Ubuntu Wiki

StableReleaseUpdates

Why

When

High-impact bugs

Other safe cases

New upstream microreleases

Staging low priority uploads

ESM Uploads

General Requirements

Development Release Fixed First

Newer Releases

Procedure

SRU Bug Template

Bug references in changelogs

Staging an upload

Landing an upload blocked by staging

Responsibility for SRU verification and cancellation of incomplete verification

Publishing

Phasing

Investigation of Halted Phased Updates

SRU team documentation

Verification

Autopkgtest Regressions

Expected resolution for reported autopkgtest failures

Removal of updates

Regressions

Testing for Regressions

Documentation for Special Cases