SRUPolicy

StableReleaseUpdates (SRU) are package updates to fix critical bugs in supported releases.

Resources

Getting Involved

Here are some tasks to get involved in the SRU process:

SRU preparation

Grab a bug from the list of accepted bugs, assign it to yourself and prepare a Stable Release Update:

  1. Prepare a new package to upload to -proposed.
  2. Update the bug with a proper SRU report.

SRU verification

Test bugs from the list of verification-needed bugs in order to validate an SRU from -proposed and move it to -updates.

TODO: verification-needed bug links.

Process overview

The Ubuntu Server team process to track potential SRU candidates and turn them into proposed updates looks like this:

sru_process-0.1.png

SRU states

A SRU can be in the following states:

sru_state-0.1.png

Weekly bug suggestions review

A list of suggested bugs for SRU is sent out to the ubuntu-server mailing on a weekly review to request feedback on relevant bugs.

Weekly suggestions email template:

Subject: Weekly suggestions of bugs for Stable Release Updates

Howdy,

We'd like to get your suggestions on the bugs listed below that may be
considered for a Stable Release Update [1] by the Ubuntu Server team if
they meet the SRU criteria.

= SRU criteria =

As outlined in the Stable Release Updates Policy [1], Stable Release
Updates will, in general, only be issued in order to fix *high-impact*
bugs.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates#When

Examples of such bugs include:

 A. Bugs which may, under realistic circumstances, directly cause a security
    vulnerability. These are done by the Ubuntu Security Team.

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

 C. Bugs which may, under realistic circumstances, directly cause a loss of
    user data.

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

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

 F. FTBFS (Fails To Build From Source) can also be considered. Please note
    that in main the release process ensures that there are no binaries which
    are not built from a current source. Usually those bugs should only be 
    SRUed in conjunction with another bug fix.

For new upstream versions of packages which provide new features, but don't fix
critical bugs, a backport [2] should be requested instead.

[2]: https://help.ubuntu.com/community/UbuntuBackports

= How-to suggest a bug for a SRU =

If you find a bug below that would qualify as a Stable Release Update according
to any of the criteria outlined above you can suggest it by replying to this
email mentioning the bug number and the criteria letter (as defined above):

  * bug 12345 - ...
  [....]
  +1: A

  * bug 67890 - ...
  [....]
  +1: D

Bugs listed below that will not be suggested in one week on Friday, June 24th
will be automatically declined.

= List of bugs =

== dapper ==

 * bug 594544 - dhcp3 - medium 
   Get prompt about modified config file on upgrade from hardy to lucid 
   http://bugs.launchpad.net/bugs/594544

 * bug 572410 - samba - medium
   nmbd doesn't start because of missing testparm 
   http://bugs.launchpad.net/bugs/572410

== lucid ==

 * bug 591802 - tomcat6 - high 
   tomcat fails to start using a security manager 
   http://bugs.launchpad.net/bugs/591802

== Bugs fixed in the development release over the last week ==

 * bug 590629 - dbconfig-common - whishlist
   Please sync dbconfig-common 1.8.46 (main) from Debian unstable (main). 
   http://bugs.launchpad.net/bugs/590629

Thanks,

SRU tracking DB

Each SRU is tracked in database in order to be able to calculate the age of each state it has been in. Scripts generate bug lists for each state on a regular basis and store the results into a local DB.

The SRU tracking DB is managed by scripts from the Server SRU tracker project on Launchpad.

SRU tracking page

The SRU tracking page lists the bugs currently under SRU, their state and how long they've been into that state.


CategoryServerTeam

ServerTeam/SRUPolicy (last edited 2010-12-22 21:17:08 by robbie.w)