Re: glibc and UNACCEPTs

[Ian Jackson <ian@davenant.greenend.org.uk>]

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.