Anthony Towns writes ("glibc and UNACCEPTs"):
> ... how we can avoid this class of problem in future, given the safety
> net that caught us this time is going away?Ideally, there would be some automatic checks that could spot `probably erroneous' uploads, and which you would mention in your .changes file if you were violating them. Elsewhere in this thread it has been pointed out that that upload would have pushed unstable across experimental's version number, which is probably a reasonable thing to require confirmation of intent for. Other possibilities for `yellow flags' include: * any upload shortly before the relevant freeze * `unexpected version number jumps; something in the package could specify what an `expected' jump was for each distribution something like: Normally-No-Change: unstable ?=.?=.?+1* and then uploading 2.3.999 would require an explict request since 999 is more than 1 greater than 6 (from 2.3.6-19, the old version in the archive). Each maintainer could set the `safety catch' appropriately eg by setting Normally-No-Change: unstable ?=.?=.?= when you settle on the upstream version for etch. * package is on `extra care' list maintained by ftpmasters and perhaps people can think of more. To make this work reasonably, you'd have to be able to resign the .changes with additional acknowledgements of the yellow flags (`yes, I really mean this) and reupload it, with the same version numbers of the underlying files. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
