This page outlines the requirements for SRU preparation and acceptance.

It would help to describe what an SRU is!

This document is a draft.


  • A contributor who is preparing an update for a stable release.
  • A member of an SRU team who is responsible for approving requests for SRUs.

Preparing an SRU

We will assume that the update in the development release has already been done.

There will be at least one stable release for which the update must be done. The fix for each stable release may be the same, or different, and they may be the same or differ from the fix for the development release.

  1. Get the appropriate packages for the stable update to be based on for each release that must be updated, taking in to account the packages already in -security/-updates/-proposed.
  2. For each release that must be updated prepare the change, either by writing it from scratch for a release if a different fix is needed there, or re-using the fix from an already prepared release.
  3. Once the updates are prepared seek approval from the appropriate SRU team for the change. This step may come earlier in some cases. The SRU team may or may not want to see the specific changes, but providing them would reduce round-trips. This may be an iterative improvement of the changes.
  4. Once approval has been granted upload/seek upload of the updated packages to the correct distribution for each.

Reviewing an SRU request

There are currently two SRU teams, one for main, one for universe. I don't think discussion of SRUs in a seed-based world has taken place yet. In the following discussion I will talk about one team only, and treat it as if it were the only one, and any packages that they are not responsible for do not exist.

There must be a list of outstanding SRU requests that need review. This should be split in to those that are pending review, and those that have been reviewed and found lacking, but not rejected. It would probably also be good to be able to get a list of the accepted requests that haven't been completed so that it can be checked that nothing is getting dropped.

The list of outstanding reviews will be processed and assesed, possibly viewing the code changes.

***This is a draft, and in fact wrong, it will be corrected in consultation with the associated teams later***


DistributedDevelopment/Requirements/SRU (last edited 2010-03-11 16:49:37 by barry)