[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: glibc and UNACCEPTs

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.

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

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

Really 4) should be done in any case, but I can understand it could get
annoying at times.

Thanks for listening,


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

Reply to: