Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
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/
Reply to: