important changes to the Stable Release Updates procedure

[Steve Langasek]

Dear developers,

At UDS this month, members of the SRU team sat down to talk about how to
best structure the SRU process going forward.  Between changes to the
staffing of the SRU team, and the 12.04.1 point release less than three
months away, it was clear to everyone that we needed an SRU process that is
responsive, scales to the number of SRUs we can expect, and facilitates SRUs
moving successfully through the pipeline, avoiding stalls in the middle.

To that end, a number of changes have been agreed that are being put into
effect immediately.  The first of these is that, as some of you will have
already seen, the SRU procedure documented on
<https://wiki.ubuntu.com/StableReleaseUpdates#Procedure> is now being
rigorously enforced.  This means that uploads to the -proposed queue for
packages which do not have the necessary information in their linked bug
reports will be summarily rejected from the queue.

This is a necessary step to prevent the SRU queue from being clogged by
packages that are unlikely to ever be successfully verified and promoted to
-updates.  That's precisely why this procedure was written in the first
place; however, in practice the SRU team has been very lenient about
enforcing these requirements.  This lenience is now at an end.  While this
means SRU uploaders will be asked to write more on each bug they propose to
SRU for, this is not bureaucracy for its own sake.  Rather, by asking
uploaders to make the SRU bugs information-complete before uploading, we
ensure that the accepted packages can be verified efficiently, and that both
the SRU team and the uploaders are prioritizing the right bugfixes in the
SRU process.

That said, even if you are already familiar with the SRU procedure, it would
be a good idea to review the wiki page; because at the same time that we're
enforcing the procedure, we are also simplifying the requirements to try to
make it easier for uploaders to comply with.  The following changes are
being made to the process, effective immediately:

 - The [Development Fix] and [Stable Fix] sections are no longer required.
   Instead, we expect this information to be visible from the state of the
   per-package tasks on the bug.
 - The [Regression Potential] requirement has been clarified, to state that
   the purpose of this section is to guide testers in focusing their
   attention on areas where regressions may occur.
 - The [Impact] header is optional - although the information is not!  Any
   SRU bug should have a clear bug description that makes it clear why an
   SRU is warranted, as well as making it clear what the bug is.  You just
   aren't expected to have a special header to communicate this.

Thanks to all our SRU uploaders for their cooperation with this renewed
policy.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-announce/attachments/20120530/d62d2c15/attachment.pgp>