Hi *, 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.
It was lucky that was possible -- I should've been asleep at the time, and if it had taken even an hour longer to notice, it would have been too late. UNACCEPTs are awkward even at the best of times -- it will now require manual intervention to fix the buildds so that they'll notice any glibc uploads to unstable with a version less than 2.3.999.2-10, and thus make 2.3.6-19 available for anything other than amd64. That's time taken away from other work that would benefit the release or the build infrastructure. The reason I'm pointing this out at length is to emphasise that as we improve the archive software this will become not just awkward to do, but *impossible*. While this will make development easier and the archive more reliable, mistakes like the above -- introducing an experimental version of glibc into unstable in a careless upload just as the RMs are trying to freeze base -- will need to be caught by maintainers before doing an upload. Seriously: that was probably an historic event in that it's likely the last UNACCEPT that'll happen. Which means we'll be relying heavily on maintainers taking the care we're used to *all* the time, not just 99.99% of it. We have a lot of tools in our QA arsenal, but they don't do us any good if we do a rush job and don't use them... 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? Cheers, aj
signature.asc
Description: Digital signature
