Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
On Thu, 08 Jan 2009, Ian Jackson wrote:
> 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.
It might influence our opinions if that's a question for the TC however.
It might also change the recommandation that the TC does. So I think it's
important to continue this part of the discussion nevertheless.
> 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.
That's granted, but then it's irrelevant to my point. The job of the
ftpmasters is mainly:
- verifying licenses for DFSG compliance
- maintaining the archive
It has never been a primary task for them to check the quality of software
that is packaged, except for obvious errors (such as policy-compliance
one) that they spot while they are doing other tasks. Using the 2.2.1
criteria of the policy does not qualify as "obvious errors" IMO (otherwise
we wouldn't be here discussing this).
> > 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.
Yes. But there are limits on their responsibilities.
> > 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.
So Gerrit should contact the leader or try a GR to be able to package
qmail? I'm not sure that's the proper way either.
> > 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.
FTPMasters are our experts in licenses and archive maintenance. They are
not FTPMasters because they are experts in quality review of our software
(they might be, but it's not required to accomplish their primary task).
Let me try a parallel with the way I manage Alioth. When we created the
service, we defined a policy:
http://lists.debian.org/debian-devel-announce/2003/03/msg00024.html
Now I have received project requests that IMO clearly would go nowhere
or would only result in crappy apps. But they were requested by DD and as
such they were approved because they matched the policy that we set out
for running the service.
In the case of ftpmasters, their policy for NEW checking is only
documented in their reject FAQ:
http://ftp-master.debian.org/REJECT-FAQ.html
The only point relevant here is: "trying to reduce the number of bugs in
Debian" (least priority) and they clearly explained the problem that they
are not doing a full review: "Not all QA issues will be noticed; we don't
test packages, but we do look through them and note problems that jump out
at us."
We all know how NEW processing regularly result in complaints. Trying to
enhance the policy to be more fair could help. IMO the quality issues that
are not covered by an explicit policy point should result in bugs being
filed and not in package rejects. Bugs are the basis that we use to
evaluate quality and decide of package inclusion in our stable releases.
BTW, if some ftpmasters are still following, it would be great if you
could update http://wiki.debian.org/Teams/FTPMaster with first-hand
information like most major teams have done.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: