Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
On Wed, Jan 07, 2009 at 08:53:24AM +0100, Raphael Hertzog wrote:
> > Individual developers make decisions all the time about whether software is
> > Too Buggy To Live, when they decide whether or not a package should be
> > uploaded yet to the archive. The ftpmasters also have to make decisions on
> > the same question when they do NEW processing. In the rare cases when the
> > ftp team and the uploader reach a different conclusion, it's altogether
> > reasonable to ask the TC to adjudicate.
> I don't agree that the ftpmasters "have to make decisions on the same
> question".
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?
I have no doubt at all that it's 1), because it's plainly written in Policy
that packages in main "must not be so buggy that we refuse to support them",
and the ftp team are who controls whether a package is in main.
I happen to disagree that the ftp team's current standards of bugginess are
appropriate, because they're taking liberties to set standards that don't
follow from Debian Policy - but that's a separate question, and doesn't lead
me to a different conclusion than the one they've reached regarding the
current qmail package.
> In fact, I tend to think that Qmail is special-cased because it's popular
> and the problems are well known.
The ftp team reviews all new packages to determine whether they're suitable
for main, so that's not a special case. What's special is that the ftp team
can reach a decision of "too buggy" more easily because they have more
information available than they do about the average package. Would you
have the ftp team wear blinders and ignore all information they didn't learn
by inspecting the uploaded package? I don't think that's reasonable; I
expect the ftp team to bring all their expertise to bear when making
decisions about what belongs in the archive.
(If an ftp team member had independent knowledge that a package violated
copyright law, should he ignore this fact and make a determination based
only on the debian/copyright file?)
> I think that ftpmasters are not always doing a thorough analysis of the
> quality of the source code and are not usually evaluating the impact of each
> package on the global net. (And while such an evaluation would always be
> positive because it could lead to bugreports and improvements, I don't
> think it's the job of the ftpmasters to do it.)
I would be happy to see a group of interested developers provide the same
level of scrutiny to other NEW packages that don't have such a high profile,
to determine whether they're also fundamentally dangerous to include in the
archive. But a) we shouldn't block packages in NEW while waiting for such
volunteer resources to materialize, and b) packages that have known problems
shouldn't be allowed into the archive due to some misguided concept of
"fairness".
> Given that the definition of crap will change from developers to
> developers, and until we have an agreed upon definition of crap,
> I don't think it's reasonable to expect the ftpmasters to filter
> out crap that some Debian developers want to maintain.
Why not? If the maintainer disagrees, there's a procedure for resolving the
dispute - appeal to the TC.
But it's certainly not the case that developers have a *right* to have any
free software they choose to maintain accepted into the archive.
> But up to now, and ever since I joined, Debian has been the universal OS
> where you could find any DFSG-free software that a Debian developer
> decided to package. We did not have any restriction such as the one we're
> currently discussing.
This is an interesting claim that gives me pause for thought. I'm not sure
that it's true, but I also don't know of any specific counterexamples.
Regardless, while it's interesting to consider whether there is precedent, I
don't think this changes my opinion that allowing software into main is an
area of shared authority between the maintainer and the ftp-team.
> > (I'm not saying that qmail must not be allowed in the archive; I'm only
> > saying that it's not a foregone conclusion that we should allow it in
> > because there's a Debian developer who wants it there.)
> I agree that it's possibly no longer a reasonable rule given our size, but
> I think such a change need to be officialized in some other ways than
> "ftpmasters have decided that crap is no longer allowed". :-)
Note that several of the issues that I consider blockers for the package's
acceptance into the archive are codified in Policy, which is where we as a
project get our definition of software that's "too buggy to live".
Issues that are not Policy violations - i.e., grave and critical bugs - are
currently defined/handled ad hoc, by a combination of the ftp team, the
debbugs team, the release team, and the QA team. I think grave/critical
bugs are equally valid reasons to reject packages out of NEW, but you're
right that there's no clear path by which the authority to reject these
packages flows from the project to the ftp team.
We as a project should correct this - which I think means getting the DPL to
make an explicit delegation of the power to block packages from the archive
that fail our traditional grave/critical bug criteria.
--
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: