Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
On Tue, 06 Jan 2009, Ian Jackson wrote:
> Raphael Hertzog writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian"):
> > I'm particularly uneasy with letting the ftpmasters decide
> > what's acceptable in the Debian archive on some non-usual policy
> > requirements that can be difficult to justify.
>
> 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").
IMO, the job of "supporting the software" is done by the maintainer and
the security team, and it's their decision whether they can support the
software or not.
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.
> 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".
In fact, I tend to think that Qmail is special-cased because it's popular
and the problems are well known.
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.)
> > have a maintainer and some reasonably popular piece of software, we
> > should accept it in the archive. Note: it's not the same as accepting it
> > in our stable release where all our usual criteria do apply.
>
> I don't agree that popularity + maintainer activity are sufficient to
> justify allowing a package into the archive.
>
> Put another way: I don't believe that the sets "software that's reasonably
> popular and has a maintainer" and "crap" are disjoint.
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 agree however that it would be good to try to define more precisely
what's acceptable in Debian and what's not.
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.
> (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". :-)
Maybe a DEP driven by the ftpmasters would be a good idea?
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: