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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
-- ubuntu-devel-announce mailing list ubuntu-devel-announce@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
