Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
On Sat, Jan 10, 2009 at 04:35:59PM +0100, Raphael Hertzog wrote:
> > There are three possibilities here:
> > 1) The ftp team have a duty to judge whether a NEW package is too buggy to be
> > allowed into the archive.
> > 2) The ftp team may exclude NEW packages from the archive that they believe
> > are too buggy, but do not have an obligation to do so.
> > 3) The ftp team must not exclude NEW packages from the archive on the basis
> > that they consider them buggy.
> > Which of these are you arguing holds?
> 2.
> I believe they don't have a duty to judge the quality but they have to
> take into account the input that all DD (and that includes ftpmasters
> themselves) might have left on the ITP bugs. They must weigh the
> arguments given and give some more importance to any reservation
> of the security team (and possibly release/qa team).
I would draw a distinction here between "investigate the quality in depth"
and "judge the quality". I don't think the ftp team has an obligation to do
a lot of investigation, and I think the project as a whole is happier if
they don't do this (since it would cause the NEW queue to be more of a
bottleneck). But they do make a judgement call on the quality of each
package that they let into the archive, based on the available information.
> > Why not? If the maintainer disagrees, there's a procedure for resolving
> > the dispute - appeal to the TC.
> 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"?
Would giving the ftp team explicit authority to block packages that
obviously fail this standard resolve the dispute?
> 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.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: