The Dear Project Leader wrote: > Yesterday, glibc 2.3.999.2-10 was accidently uploaded to unstable instead > of experimental, and on the request of the release managers, I UNACCEPTed > it, given it was a major accidental change to a rather core library just > as that library should've been frozen. > ... > > The 2.3.999.2-10 upload (with signatures removed) is available on > ftp-master.debian.org/~ajt/glibc/. Would anyone like to contribute their > thoughts, so we can do an "air crash" style failure analysis to work > out how we can avoid this class of problem in future, given the safety > net that caught us this time is going away? > Unfortunately it's happened against, this time with the upload of xorg-server (xserver-xorg-core) 1:1.1.1-3, accidentally uploaded to unstable instead of experimental. An easy enough mistake, it's only one little field in a changelog file. I can think of only a handful of reasonable changes we could make to reduce these occurances: 1) [technical] Alter dput/dupload to explicitly ask whether to proceed if the distro from the preceding changelog entry changes (e.g. experimental->unstable) 2) [technical] Remove the single point of failure by adding a Distribution: field to debian/control, say. The package will be rejected if the two fields in control and changelog do not match. 3) [policy] Manual processing by ftp-masters when changing distro. Their decision is automatic rejection by default unless there is a changelog entry explicitly stating the distro change is occurs. This need only apply for uploads to unstable (or stable), not for uploads to experimental. 4) [human engineering] For team-supported packages, require that another member of your team verify the package (with special attention to the distro field in debian/changelog) before uploading. It would be nice to see 1) done. A Previous-Distribution: field in .changes filled in during a dpkg-buildpackage run might help to facilitate it. dpkg-buildpackage could check and reject for 2) at build time. Perhaps 2) could be combined with 1) (dput/dupload make two separate checks) Unless 2) is practical to implement, then 3) is a very good idea, in my opinion, since it removes the single point of failure. No longer will there be just one single field to be miswritten. Manpower-wise, however, I don't know if it would make too much burden on the ftp-masters. Really 4) should be done in any case, but I can understand it could get annoying at times. Thanks for listening, Drew p.s. the old xserver-xorg 1:1.0.2-9 packages can still be found in testing, or you can grab the new video drivers from experimental. The full working set of X11R7.1 packages will all be in unstable "soon" (in the next week or so), pending adjustments in versioned depends of the video drivers.
Attachment:
signature.asc
Description: This is a digitally signed message part