Special types of SRU

What is acceptable to SRU, together with other considerations, give rise to the following special types of permitted SRU, some of which overlap:

  • Package-specific non-standard process: for routine non-standard cases, we create package-specific notes for consistency. These may incorporate any of the other special types below and may include any exceptions to our usual criteria that have been approved by the Technical Board.

  • Hardware enablement: for Long Term Support releases we regularly want to enable new hardware [criteria].

  • Environmental change: updates that need to be applied to Ubuntu packages to adjust to changes in the environment, server protocols, web services, and similar [criteria].

  • Autopkgtest fix: autopkgtest fixes may be included in SRUs. An update that fixes only autopkgtests is also acceptable, but should normally be staged [criteria].

  • Extended Security Maintenance: there are special procedures for uploads to stable releases in their Extended Security Maintenance (ESM) period. Please prepare the SRU bug and then contact the ESM team.

  • Staged upload [explanation], [how-to: stage upload], [how-to: land staged upload].

  • Upload to the new queue of an active release [explanation], [how-to: new source or binary].

  • Bundled upload: an SRU performed “on top” of an existing package already in -proposed. [TBC]

  • New upstream release:

    • New bugfix-only upstream release

      Bugfix-only releases are acceptable if all changes are appropriate for an SRU under our normal criteria, by one of two paths:

      1. The upload may use the new upstream orig tarball, but with individual Launchpad bugs to track verification of each fix individually.

      2. Instead, if upstreams meet, in the opinion of the SRU team, our more specific QA criteria for upstream microreleases then it is acceptable to process them with a single tracking bug instead of individual Launchpad bugs for each fix. If relying on this path, the upstream QA process that meets this criteria must be documented/demonstrated and linked from the SRU tracking bug.

    • New upstream release that adds features without breaking existing behaviour

      For Long Term Support releases we sometimes consider it appropriate to introduce new features. We may choose to do so we can do this safely. However, to meet expectations of release stability, we will consider these on a case-by-case basis [criteria].

    • New upstream release that changes existing behaviour

      Deliberately changing existing behaviour is to be avoided due to our minimise regression principle, so such SRUs are generally not permitted. Exceptions may be granted by the Technical Board, but require exceptional justification. Standing exceptions are documented in Package-specific notes.

  • Removals: in rare cases, a package is or has become actively harmful to users, and is replaced by an empty package [explanation].

  • Security updates: these usually follow a different process and are out of scope of the SRU team and processes documented here. See Security team’s Update Procedures for details [explanation].