Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
On Fri, 09 Jan 2009, Steve Langasek 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?
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 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.
As I told elsewhere, it's the people who have to do the support that
should decide if they can do it, and not the ftpmasters. That means mostly the
maintainer himself and the security team.
> 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
Of course no. I was just pointing out that if we consider it a duty of the
ftpmasters to judge quality, then the treatment of qmail was unfair
compared to all the other crap that got in without review.
But as I'm not the one arguing that it's a duty, I don't have a problem
with the unfairness if the process is clear and doesn't give the
ftpmasters any special powers in the standard quality review process.
(Yes my point of view is slowly evolving with the discussion)
> > 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.
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.
> 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.
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.
<digression: another reason for unsupported>
For instance I maintain sql-ledger but it has no proper security support
and it's "documented" in the README.Debian and the security team has
documented it with the tags secteam::etch-limited-support and
Given this, I think that "main" is not the proper place for that software.
But I need it, and I know others who rely on it and I want to continue to
maintain it in Debian until a viable replacement is packaged.
Le best-seller français mis à jour pour Debian Etch :