On Mon, 12 Jan 2009, Steve Langasek wrote: > > Whoever takes the decision, we still need an agreed upon definition of > > crap, otherwise people will be unhappy to not be able to maintain the > > piece of software they care about. Even if that software is crap. > > Do the definitions of "grave" and "critical" bugs found in the BTS > documentation serve, in your opinion, to identify software that's "crap"?
Yes, but only if they can't be fixed (or if they can but aren't because upstream doesn't want to and/or the maintainer doesn't have the required skills). > Would giving the ftp team explicit authority to block packages that > obviously fail this standard resolve the dispute? It's certainly a good step to clarify the situation. > > Well, maybe it should. But that right could be limited to a sub-part of > > Debian called "unsupported". It's IMO important to leave a chance to each > > DD to use the Debian infrastructure (BTS/buildd) to improve software that > > they would like to see integrated in Debian. > > Personally, I don't agree. If a package fails the most basic QA criteria, > I think it's reasonable to require the maintainer to address this before > allowing the package into the archive where it will consume central project > resources (especially mirror network space, which is one of the resources > with the highest per-package cost, and does not scale linearly). > > OTOH, suppose that a package is rejected from the NEW queue because the > ftp team notices a grave bug, and the maintainer reuploads fixing this grave > bug and the ftp team then notices a second grave bug that was already there. > Rejecting the package a second time will frustrate the maintainer and seems > unnecessary from the standpoint of protecting the quality of the archive, > since the maintainer has already demonstrated a committment to addressing > major issues. This ties into Sam's comments about encouraging "processes > that enable individuals to make forward progress", which are spot on. Indeed, I consider this an acceptable compromise but one that is not so easy to put in place. In particular when multiple people do NEW processing. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
