StableReleaseUpdates

Differences between revisions 72 and 404 (spanning 332 versions)
Revision 72 as of 2007-11-08 16:43:07
Size: 13042
Editor: pool-71-124-234-44
Comment:
Revision 404 as of 2025-06-25 19:59:52
Size: 14476
Editor: ahasenack
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;">'''Contents'''[[BR]][[TableOfContents]]||

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

This Policy applies for packages shipped in Main. For packages in universe read [:StableReleaseUpdates#Universe].

There is an automatically generated list of [http://people.ubuntu.com/~ubuntu-archive/pending-sru.html packages which currently undergo this process].
||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>||

{{{#!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
}}}
Line 11: Line 11:
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 19: Line 17:
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'''
 * Bugs which represent '''severe regressions''' from the previous release of Ubuntu
 * Bugs which may, under realistic circumstances, directly cause a '''loss of user data'''

== How ==

This process is to be followed for all updates '''except''' those to fix security updates, which are only released by the Ubuntu security team. Security procedures are documented at SecurityUpdateProcedures.

For updates to source packages in the `universe` or `multiverse` components, see [:StableReleaseUpdates#Universe]. Any `main` source packages with binary packages that cross components will have all of their packages examined under this policy.

 1. Propose
 
  All proposals for stable release updates must be '''approved''' by a member of the [https://launchpad.net/~ubuntu-sru Stable Release Updates team]. Attach all of the information to the existing bug report, use ''Nominate for release'' to mark the bug for backporting, then subscribe the `ubuntu-sru` team. If more than one bug is being addressed, each bug must be handled, justified, approved separately, and uploads will only be approved if all involved bugs are. SRU proposals ''must'' be accompanied by the following information for each bug to be addressed:

   1. A '''statement explaining the impact''' of the bug on users and justification for backporting the fix to the stable release
   1. An explanation of '''how the bug has been addressed''' in the development branch, including the relevant version numbers of packages modified in order to implement the fix; generally, SRUs will not be accepted if the bug has not been fixed in the development branch.
   1. A '''patch''' applicable to the stable version of the package. If preparing a patch is likely to be time-consuming, it may be preferable to discuss the first three items before preparing a patch. The patch must be as small and unintrusive as possible.
   1. Detailled '''instructions''' how to reproduce the bug. These should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. These need to be put into the '''description''' of the bug (not just another comment), after a line which contains "{{{TEST CASE:}}}".
   1. A '''discussion''' of the regression potential of the patch and how users could get inadvertedly effected.

  The bug tasks need to accurately reflect the state in all releases and the proposed SRU targets. This makes it much easier for the SRU team to assess the state of the bug without having to wade through a long discussion in the bug's history.

 1. Prepare

  Once an update has been discussed and approved in principle, an upload can be prepared. The following criteria apply to any packages modified as part of the update:

   1. The changelog entry and resulting .changes file must include a reference to the corresponding '''bug report(s)'''
   1. The bug report must include an '''approved SRU proposal'''
   1. The '''version number(s)''' must be carefully checked in order to avoid clashing with any other version of the package, past, present or future
   1. The upload target must be ''release''`-proposed`
   1. The package difference must be a minimal change to fix the bug. For exceptions to this, see /MicroReleaseExceptions. Spurious changes to build systems, documentation, functionality ''will be rejected''.
   1. Make sure to generate the `.changes` file against the current version in `-proposed` or in `-updates`, using the `-v` option to `dpkg-buildpackage` or `debuild`.

  Uploads which do not meet these criteria will be '''rejected''' by an archive administrator and not published. Once the upload is ready, attach a complete source package diff (`debdiff`) to the bug report for review.

  Usually it is fine to upload the package, so that it is readily available for review for the SRU team. However, if you have doubts if your change is appropriate, please wait for the approval in the bug trail before upload. Inappropriate uploads will be rejected and commented on in the bug. Uploads with no or an invalid bug number in the changelog will be rejected.

 1. Upload

  The upload will be reviewed by the SRU archive administrators during regularly scheduled processing, and approved if it meets the above criteria. Archive administrators should verify that the package delta matches the debdiff attached to the bug report.

  The `ubuntu-archive` team member who accepts the package into `-proposed` should:
   1. Add a `verification-needed` tag to the bug report.
   1. Set the bug report to '''Status: Fix Committed'''.
   1. Subscribe the `sru-verification` team.

 1. Test

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

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

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

   1. Set the bug report '''Status: In Progress'''
   1. Describe why the fix was rejected in a comment to the bug report.
   1. Remove the `verification-needed tag`.

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

   1. Modify the `verification-needed` tag to a `verification-done` tag on the bug report.
   1. Describe the general steps taken to verify the package, any special difficulties, and the recommended upload date.

 1. Release

  After the package in `-proposed` has been successfully tested and passed a minimum aging period of '''7 days''', and is approved for upload to ''release''`-updates` by the SRU verification team, the `ubuntu-archive` team member who accepts the package into `-updates` should:
   1. Copy the source and binary packages from `-proposed` to `-updates`.
   1. Set the bug report to '''Status: Fix Released'''.
   1. Remove the proposed package from `-proposed` (subject to [https://bugs.launchpad.net/soyuz/+bug/56037 bug 56037]).

 1. Follow up

  1. Add yourself as a '''bug contact''' for the package in Launchpad, if you are not one already
  1. For 7 days after the update is released, '''monitor Launchpad''' for bug reports relating to the update
  1. In the event of a regression, '''immediately''' notify the [mailto:technical-board@lists.ubuntu.com Ubuntu Technical Board] via email, and ask for help on `#ubuntu-devel` in making urgent contact with a member of the Board.

[[Anchor(Universe)]]
== Packages in Universe/Multiverse ==

For packages in the Universe and Multiverse components, whilst they are popular, they are not installed by default and therefore have a lower risk of affecting many users if a regression occurs.

Therefore the rules above apply with the following changes:

 1. Prepare
  * Any MOTU can decide that particular issue is good candidate for SRU and can prepare the update package for `<release>-proposed`
  * The sponsor of the upload is responsible for testing the update, although responsibility for follow up thereafter may be negotiated between the sponsor and contributor.
  * The bug tasks need to accurately reflect the state in all releases and the proposed SRU targets. This makes it much easier for the sponsor to assess the bug without having to wade through a long discussion in the bug's history, as well as not accidentally closing bugs for the development release. Nominations should be approved if a developer believes that the issue meets, or may meet, the criteria above: please ask in #ubuntu-motu to request approval for a nomination.
 1. Test
  * Notify the MOTU team via the ubuntu-motu mailing list [mailto:ubuntu-motu@lists.ubuntu.com <ubuntu-motu@lists.ubuntu.com>] of the availability of this package for testing
  * Prepend "StableReleaseUpdates" to the Subject line of your e-mail.
  * Add a `verification-motu-needed` tag to the bug report.
  * Test the package yourself
  * If the testing period is over and there 2 persons have stated "works for me", set the tag `verification-motu-done`.
  * Note, this doesn't have to be necessarily a MOTU marking it as "works for me". Two community members will suffice.
 1. Release
  * After at least '''2 persons''' have tested the package and attached a "works for me" comment to the bug and after a minimum aging period of '''7 days''', the archive administrators will copy the package into ''release''`-updates` and close the bug. To make them aware of this, modify the bug status as follows:
  * Modify the `verification-motu-needed` tag to a `verification-motu-done`, so that it appears on the [https://bugs.launchpad.net/ubuntu/+bugs?field.tag=verification-motu-done list of verified universe SRUs] ([https://bugs.launchpad.net/ubuntu/feisty/+bugs?field.tag=verification-motu-done list of verified universe SRUs for Feisty]).
  * Subscribe ubuntu-archive to the bug so that the archive administrators are aware that it needs to be copied over to -updates.
 1. Following Up
  * Add yourself as a '''bug contact''' for the package in Launchpad, if you are not one already
  * For 7 days after the update is released, '''monitor Launchpad''' for bug reports relating to the update
  * In the event of a regression, '''immediately''' notify the [mailto:ubuntu-motu@lists.ubuntu.com Ubuntu Universe maintainers] via email, and ask for help on `#ubuntu-motu`.

[[Anchor(Special)]]
== Special Cases ==
{{{#!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

== Procedure ==

{{{#!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 ==
<<Anchor(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)

<<Anchor(Special)>>
== Documentation for Special Cases ==

{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/

See the announcement: https://lists.ubuntu.com/archives/ubuntu-devel/2025-June/043391.html
}}}
Line 129: Line 143:

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)
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#kernel
}}}

=== Landscape ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#landscape
}}}

=== Snapd ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#snapd
}}}

=== Snapcraft ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#snapcraft
}}}

=== Ubuntu-image ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#ubuntu-image
}}}

=== Docker.io group ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#docker-io-group
}}}

=== gce-compute-image-packages ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#gce-compute-image-packages
}}}

=== google-compute-engine ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#google-compute-engine
}}}

=== google-compute-engine-oslogin ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#google-compute-engine-oslogin
}}}


=== google-guest-agent ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#google-guest-agent
}}}

=== google-osconfig-agent ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#google-osconfig-agent
}}}

=== curtin ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#curtin
}}}


=== walinuxagent ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#walinuxagent
}}}

=== GNOME ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#gnome
}}}


=== OpenStack ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#openstack
}}}

=== Certbot ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#certbot
}}}

=== cloud-init ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#cloud-init
}}}


=== DPDK ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#dpdk
}}}

=== ubuntu-release-upgrader and python-apt ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#ubuntu-release-upgrader-and-python-apt
}}}

=== apt and python-apt ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#apt-and-python-apt
}}}

=== rax-nova-agent ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#rax-nova-agent
}}}

=== livecd-rootfs ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#livecd-rootfs
}}}

=== fwupd and fwupdate ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#fwupd-and-fwupdate
}}}

=== snapd-glib ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#snapd-glib
}}}

=== netplan.io ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#netplan-io
}}}

=== ec2-hibinit-agent ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#ec2-hibinit-agent
}}}

=== NVIDIA driver ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#nvidia-driver
}}}

=== wslu ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#wslu
}}}

=== openjdk-N ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#openjdk-n
}}}

=== Postfix ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#postfix
}}}

=== sosreport/sos ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#sosreport-sos
}}}

=== oem-*-meta ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#oem-meta
}}}

=== ubuntu-dev-tools ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#ubuntu-dev-tools
}}}

=== OpenLDAP ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#openldap
}}}

=== HAProxy ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#haproxy
}}}

=== autopkgtest ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#autopkgtest
}}}

=== squid ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#squid
}}}

=== bind9 ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#bind9
}}}

=== virtualbox ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#virtualbox
}}}

=== ubuntu-advantage-tools ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#ubuntu-advantage-tools
}}}

=== open-vm-tools ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#open-vm-tools
}}}

=== postgresql ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#postgresql
}}}

=== GRUB ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#grub
}}}

=== OpenVPN ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#openvpn
}}}

=== Language Packs (language-pack-*) ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#language-packs-language-pack
}}}

=== cd-boot-images-<arch> ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#cd-boot-images-arch
}}}

<<Anchor(Security)>>
== Data Packages Kept in Sync with Security ==
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#data-packages-kept-in-sync-with-security
}}}
Line 139: Line 383:

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.
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#tzdata
}}}

=== distro-info-data ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#distro-info-data
}}}

=== linux-firmware ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#linux-firmware
}}}

=== wireless-regdb ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#wireless-regdb
}}}

== Toolchain Updates ==
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#toolchain-updates
}}}
Line 144: Line 409:
As a reference, see [https://launchpad.net/ubuntu/+source/cpio/+bug/59228 bug #59228] for an idea of how the SRU process works.

As a reference, see [[https://launchpad.net/bugs/173082|bug #173082]] for an idea of how the SRU process works for a main package, or [[https://launchpad.net/bugs/208666|bug #208666]] for an SRU in universe.

== Package Removals ==

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

== Links ==

{{{#!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/
}}}

Why

When

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/

General Requirements

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

Procedure

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

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

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

Regressions

Testing for Regressions

(defunct section removed)

Documentation for Special Cases

Kernel

Landscape

Snapd

Snapcraft

Ubuntu-image

Docker.io group

gce-compute-image-packages

google-compute-engine

google-compute-engine-oslogin

google-guest-agent

google-osconfig-agent

curtin

walinuxagent

GNOME

OpenStack

Certbot

cloud-init

DPDK

ubuntu-release-upgrader and python-apt

apt and python-apt

rax-nova-agent

livecd-rootfs

fwupd and fwupdate

snapd-glib

netplan.io

ec2-hibinit-agent

NVIDIA driver

wslu

openjdk-N

Postfix

sosreport/sos

oem-*-meta

ubuntu-dev-tools

OpenLDAP

HAProxy

autopkgtest

squid

bind9

virtualbox

ubuntu-advantage-tools

open-vm-tools

postgresql

GRUB

OpenVPN

Language Packs (language-pack-*)

cd-boot-images-<arch>

Data Packages Kept in Sync with Security

tzdata

distro-info-data

linux-firmware

wireless-regdb

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

Package Removals

Reviewing procedure and tools

Contacting the SRU team


CategoryProcess

StableReleaseUpdates (last edited 2026-03-24 09:33:35 by sally-makin)