Notes on SRUs

[Luke Faraone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here's a quick explanation of the "lifecycle of a Stable Release
Update", which I wrote in response to some questions about how the
process works.

 1) A problem is found by someone and reported in the Launchpad bug
tracker.

 2) The bug is triaged (the severity determined, steps to reproduce
distilled, and all details extracted) according to the process explained
in Bugs/HowToTriage[1]. Some bugs skip this step.
    a. It is determined whether the problem affects the current
development release of Ubuntu.
       - If so, the bug is marked "Confirmed" or "Triaged".
       - If not, the bug is marked "Invalid" or "Fix Released" depending
on the bug's previous status. See Bugs/Status[2] for more details.

 3) The bug is fixed in the current development release. (currently
Ubuntu 10.10 "maverick")

 4) It is determined whether the bug affects previous releases, and
whether the bug merits solving, that is, if the bug is "high-impact"[3].
If so, the bug is "nominated" via Launchpad as affecting that release.
Any person can nominate a bug.

 5) The nomination is approved or rejected. This has to be done by
someone with proper access rights, but you can continue on while waiting
for this to happen.

 6) You prepare and attach a "debdiff" to the bug as a patch, using the
Debdiff utility, using a version number and release appropreate for a
SRU. We upload to the "-proposed" pocket of the archive because SRUs are
tested before they are live in "-updates". (Example: "lucid-proposed" or
something similar, contrasted with the usual "maverick" in the changelog)
    a) On versioning: Use the SecurityTeam best practices[5] as a guide.
    b) If the bug affects multiple packages or we are fixing the problem
in multiple releases, attach a debdiff for each version/package to fix.

 7) Follow step 2 of the SRU procedure[5], appending the required
information to the original package description.

 8) Subscribe ~ubuntu-sponsors to your bug. (or subscribe your MOTU
contact if you have one, it's me (~lfaraone) for SEETA folks and most
Sugar issues, although anybody else can sponsor if I'm not around)

 9) Your sponsor will upload your package to the archive.

 9) An Archive Admin will publish your package to RELEASE-proposed.
People will test your package. It will either be approved and copied
over to RELEASE-updates or be rejected.

In essence, you only need to do steps 3 (optionally), 4, 6-8 of the
process, reporting the bug if it isn't already extant.

[1]: https://wiki.ubuntu.com/Bugs/HowToTriage
[2]: https://wiki.ubuntu.com/Bugs/Status
[3]: https://wiki.ubuntu.com/StableReleaseUpdates#When
[4]:
https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update%20the%20packaging
[5]: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure

Let me know if you have questions.

- -- 
Luke Faraone
http://luke.faraone.cc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkxDunsACgkQtrC51grHAgadkACgmBzgU6nuMgY5WSFewfM5T0M6
cU0AoKxBT6ll4qVISvqK1k67oLADkPi2
=67iY
-----END PGP SIGNATURE-----