Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
(This message is about whether the ftpmasters have the right to reject
packages based on the ftpmasters' own view about how buggy they are.
Note that this is a digression because this is not a technical
question. It is a question about the processes in the project, which
ultimately are the responsibility of the Project Leader. So the TC
should not attempt to rule on that aspect of this dispute, although we
might formally state our opinion.
Having said that I think it's important to support the ftpmasters'
discretion so I'm going to carry on and discuss it a bit ...)
Raphael Hertzog writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian"):
> On Tue, 06 Jan 2009, Ian Jackson wrote:
> > I'm not uneasy with this at all. The ftpmasters' job is not to decide
> > the policy and then implement it without discretion. The policy is
> > written by them and is there to help them make their decisons and to
> > help others work with them.
>
> I think you misunderstood me: by policy I meant "the Debian policy" and
> the requirements used was 2.2.1 ("must not be so buggy that we refuse to
> support them").
Policy is not a complete guide to everything that could be wrong with
a package. It couldn't be, because it would then have to list every
possible bug.
As two examples to demonstrate that policy 2.2.1 and the maintainer's
decision about bugginess is not the last word on what can go in the
archive:
* A package which in the default setup phoned home to its maintainer
might well be rightly rejected; you can't call designed-in
behaviour a bug. (This applies to qmail too but I'm just giving
an example where I hope you would agree that the maintainer
was clearly wrong.)
* The criteria for bouncing out of main into control talk about
`packages' outside main but we put installer-downloaders for
non-free stuff outside main.
> On Tue, 06 Jan 2009, Steve Langasek wrote:
> > On the contrary, I think the ftp team's behavior has been commendable here;
> > they believe qmail is sufficiently buggy that it's unsuitable for the
> > archive, but recognize that there are different opinions on this question
> > among Debian developers and that this decision is grounded in reasons that
> > fall outside the normal reasons for package rejects, so they have referred
> > the question to the TC.
>
> I'm not saying it's bad that they deferred to the TC. I agree it's good
> given the situation.
I think it's fine for them to reject it by themselves. If they want
to refer it to the TC that's good and helpful - but it's not necessary
because the decision is subject to review by the TC anyway if the
maintainer disagrees.
> 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.)
It is, however, the job of the ftpmasters to make decisions on the
basis of the information they have.
More thoroughly reviewing more popular software makes sense because
more people are likely to run it.
> 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.
I think it's reasonable to allow the ftpmasters that discretion, given
that they are (a) appointed by the Leader and thus accountable both to
the Leader and directly via GR if necessary; (b) also overrideable by
the TC.
> I agree however that it would be good to try to define more precisely
> what's acceptable in Debian and what's not.
I disagree that that would be good. What we need is good decisions,
not policies that fetter the discretion of our experts.
Ian.
Reply to: