On Wed, Aug 27, 2003 at 02:05:15PM -0500, Manoj Srivastava wrote: > On Wed, 27 Aug 2003 11:46:41 -0500, Steve Langasek <[EMAIL PROTECTED]> said: > > > Holding NMUers accountable for the quality of their uploads: yes. > > Quite. If your upload caused the situation to deteriorate, > whether you deliberately caused the change that made it so or it was > inadvertent, you are responsible.
This argument would carry more weight with me if it were possible to either
A) test the upload *completely* before making it (IE, catch all possible
FTBFS bugs or other quirks that happen when dealing with the build daemons,
many of which even a sane chroot build can't catch), or B) to back out an
upload and say "Well, damn. It has an FTBFS bug that I can't fix; I should
file a bug on *that*, and back out to the last known good copy".
Of course, the "last known good" copy is known to have an FTBFS bug, but
*that* can't be the NMUer's fault, since it existed (simply undetected)
prior to the NMU. And really, do we want it going into testing, and then
stable, with an FTBFS bug that might have been caught otherwise, but isn't
because folks are afraid to NMU stuff lest they get bitten by, say, a C
compiler semantics change that may involve restructuring fairly important
parts of the program to fix?
Until one of these two things is possible, I find it likely to make a lot
of folks who might otherwise consider NMUing (and do a perfectly good job)
unwilling to do it, because they'd then be held responsible for the fact
that the package was broken *apart* from anything they did to break it.
If they're going to have all the pain of a maintainership on the package
from then on, why shouldn't they just hijack it in the first place? I know
that if I'm going to be held responsible for everything on the package from
the last maintainer upload to the next (possibly non-existant) one, I'm
sure as heck more likely to restructure it a manner which lets me handle
it efficiently and without undue pain. And that generally means hijacking
it (or adopting it, but NMUing an orphaned package is sort of silly; you
REALLY should just adopt it if you care, since otherwise it's just going to
get dropped).
Of course, that means I'll handle about an order of magnitude fewer RC
bugs, but we didn't want to release Sarge anytime soon, did we?
Saying "well, they shouldn't NMU" is a risk, in my view, for the simple
reason that can be observed by doing a wc -l on the claims files on master.
If they aren't going to, it's very evident that nobody else is, either, and
so the NMUs just won't happen at all. And perhaps that's fine and we should
just remove the packages - but if that's the case, why are we bothering to
have BSPs every weekend, and a 0-day NMU test?
--
Joel Baker <[EMAIL PROTECTED]> ,''`.
Debian GNU NetBSD/i386 porter : :' :
`. `'
`-
pgps19BPchjEX.pgp
Description: PGP signature
