Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian

[Joerg Jaspert]

Package: tech-ctte
Severity: normal

Dear Technical committee,

the ftpteam has been thinking about the inclusion of QMail into Debian
for some time already. We feel that qmail, unless heavily patched, is
not a suitable MTA at this time and age. It is plagued by numerous bugs
(or misbehaviours, some might consider them features) and as such, in
our opinion, falls into the category of "so buggy that it is not
supportable", which is not for Debian main (Policy 2.2.1). Also, afawk,
there is no real current Upstream.

For this reason we, the ftpteam, think that QMail is not suited for inclusion
into Debian main.

Yet, we do see that there are people who want Qmail, and instead of
maintaining it in an own repository want it in Debian. As it is unlikely
that the positions of the Qmail supporters and us will change soon to
let us find a solution that works for both sides (the positions are
basically black and white here), we ask you to help resolve it,
by a ruling on this matter, following Constitution §6.1.3.


Criteria for inclusion that qmail meets:
- active maintainer (Gerrit Pape)

- security team willing to support it [1]

- license DFSG compatible


Criteria that speak against inclusion:
- no real upstream

- several shortcomings related to the MTA behaviour, including the
  backscatter spam issue, failing to use secondary MXs, ignoring
  RFC1894, and unbundling of outgoing messages (yay for traffic/resource
  waste)[2], thus being unsupportably buggy (Policy 2.2.1)

- we do have many other, way more modern and better supported,
  MTAs available.

- still, in the reupload after the initial reject[3], seems to violate
  Policy (11.6), for example by not being able to handle etc/aliases
  files as required. Needs yet another package for this.
  Here qmail-run is the MTA provider, yet it doesn't follow the must in
  policy saying "All MTA packages must come with a newaliases program".
  Instead it has a recommends on fastforward, which then provides it.

- Still seems to violate the FHS. /var/lib/qmail/queue belongs into
  /var/spool, as far as we can tell.

- Lots of symlinks in /var/lib/qmail/bin going to /usr/bin/ and/or
  /usr/sbin. This is at least sick, if not again an FHS
  violation. var/lib is for "Variable state information", not binaries
  or links to them.

- qmail-uid-gid is creating users/gids with hardcoded ids in the
  60000-64999 range. While thats allowed from policy, stating "Globally
  allocated by the Debian project, but only created on demand.", wth is
  this global registry, and is qmail registered there?
  Also seems very much 18 century to have such hardcoded lists.

- The already existing (in non-free) qmail-src package only counts
  238 installations, which doesn't seem to imply a large userbase.
  (Of course we don't know how many people have the unofficial netqmail
  packages installed)


[1] http://lists.debian.org/debian-devel/2008/11/msg00618.html
[2] http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html
[3] http://lists.debian.org/debian-devel/2008/11/msg00641.html

--
bye, Joerg
>Do you agree to uphold the Social Contract and the DFSG in your Debian
>work?
Absolutely.
(does anyone say "no" to this question? :) )

[Raphael Hertzog-3]

On Thu, 01 Jan 2009, Joerg Jaspert wrote:
> (or misbehaviours, some might consider them features) and as such, in
> our opinion, falls into the category of "so buggy that it is not
> supportable", which is not for Debian main (Policy 2.2.1). Also, afawk,
> there is no real current Upstream.

It's the first time I hear that the ftpteam has used this requirement to
reject packages. Have you used it for other packages already?

Can you point us to the current source packages so that we can have a look
at them?

> Yet, we do see that there are people who want Qmail, and instead of
> maintaining it in an own repository want it in Debian. As it is unlikely
> that the positions of the Qmail supporters and us will change soon to
> let us find a solution that works for both sides (the positions are
> basically black and white here), we ask you to help resolve it,
> by a ruling on this matter, following Constitution §6.1.3.

What constitutes for you a solution that works for both sides?  

To me, it seems that you're deferring the decision to the tech-ctte and
that the tech-ctte must decide which side is right. But I don't see any
place yet where there's room for a compromise in this situation… or do you
expect that a subset of the source packages that are concerned would be
more acceptable than others?

> Criteria for inclusion that qmail meets:
> - active maintainer (Gerrit Pape)

Gerrit is not available until end of january so it seems rather badly
timed to bring this request forward now giving no chance to Gerrit to
give his arguments.

> Criteria that speak against inclusion:
> - no real upstream

Why "no real"? Did Gerrit commit to something?

Note that "cron" has no real upstream either, yet we use and support the
package. As long Gerrit is ready to handle all the issues that pop up, I
don't see this reason as blocker.

> - several shortcomings related to the MTA behaviour, including the
>   backscatter spam issue, failing to use secondary MXs, ignoring
>   RFC1894, and unbundling of outgoing messages (yay for traffic/resource
>   waste)[2], thus being unsupportably buggy (Policy 2.2.1)

All those are good reasons to not choose the software as a user but not to
not include them in Debian. We don't know how our users are going to use
it and there might be use cases where those shortcomings are not
problematic.

We might want to document those shortcomings and in particular those that
affect the network as a whole (backscatter) so that newcomers can avoid
causing problems simply due to ignorance.

> - we do have many other, way more modern and better supported,
>   MTAs available.

Not a valid objection, we have way more window managers.

> - still, in the reupload after the initial reject[3], seems to violate
>   Policy (11.6), for example by not being able to handle etc/aliases
>   files as required. Needs yet another package for this.
>   Here qmail-run is the MTA provider, yet it doesn't follow the must in
>   policy saying "All MTA packages must come with a newaliases program".
>   Instead it has a recommends on fastforward, which then provides it.

I'm don't know the rationale of this requirement in policy, adding aliases
automatically is not really in the spirit of the policy that preserves
configuration files.

Anyway, changing the recommends to depends might be a solution.

> - Still seems to violate the FHS. /var/lib/qmail/queue belongs into
>   /var/spool, as far as we can tell.

One more symlink in the package could resolve this. And I have seen
numerous other packages that had similar problems but that have been
accepted nevertheless. I don't think that it's a sufficient reason to
reject the package. It's enougr to open a bug report against the package
but not much more.

> - Lots of symlinks in /var/lib/qmail/bin going to /usr/bin/ and/or
>   /usr/sbin. This is at least sick, if not again an FHS
>   violation. var/lib is for "Variable state information", not binaries
>   or links to them.

Same thing than above, it's not nice but it's an effective way to comply
with the FHS when upstream doesn't comply.

> - qmail-uid-gid is creating users/gids with hardcoded ids in the
>   60000-64999 range. While thats allowed from policy, stating "Globally
>   allocated by the Debian project, but only created on demand.", wth is
>   this global registry, and is qmail registered there?
>   Also seems very much 18 century to have such hardcoded lists.

Not sure about this one, some investigation needed.

> - The already existing (in non-free) qmail-src package only counts
>   238 installations, which doesn't seem to imply a large userbase.
>   (Of course we don't know how many people have the unofficial netqmail
>   packages installed)

AFAIK we don't use this criteria to accept packages but only to remove them once
we have no active maintainer any more.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Joerg Jaspert-2]

>> (or misbehaviours, some might consider them features) and as such, in
>> our opinion, falls into the category of "so buggy that it is not
>> supportable", which is not for Debian main (Policy 2.2.1). Also, afawk,
>> there is no real current Upstream.
> It's the first time I hear that the ftpteam has used this requirement to
> reject packages. Have you used it for other packages already?

I think we did, yes.

> Can you point us to the current source packages so that we can have a look
> at them?

merkel:~joerg/qmail

>> basically black and white here), we ask you to help resolve it,
>> by a ruling on this matter, following Constitution §6.1.3.
> What constitutes for you a solution that works for both sides?  

If I would know a solution thats ok for both sides I wouldn't ask
someone else to jump in.

Yet, I don't. What I see is that we do not want qmail. We do think
Debian is best off without. Obviously Gerrit thinks differently.
Unlike, for example, mplayer, this is not to solve by modifying the
package itself (in mplayers case leaving out all the problematic bits of
the source), as it's not about a not-too-important part of the source,
but about the whole application.


>> Criteria for inclusion that qmail meets:
>> - active maintainer (Gerrit Pape)
> Gerrit is not available until end of january so it seems rather badly
> timed to bring this request forward now giving no chance to Gerrit to
> give his arguments.

He got an X-Debbugs-CC on the bug and also a reject mail pointing to
it, so he definitely knows (when he reads his mail) that this is now
with the TC.

Noone said this has to be an immediate decision. I do expect the TC to
seek his input at some stage of this. Considering that none of these
packages will ever end up in Lenny, no matter what the decision is,
waiting a bit more will sure not hurt.

>> Criteria that speak against inclusion:
>> - no real upstream
> Why "no real"? Did Gerrit commit to something?

DJB isn't doing it. Some others seem to maintain some set of patches.

>> - several shortcomings related to the MTA behaviour, including the
>>   backscatter spam issue, failing to use secondary MXs, ignoring
>>   RFC1894, and unbundling of outgoing messages (yay for traffic/resource
>>   waste)[2], thus being unsupportably buggy (Policy 2.2.1)
> All those are good reasons to not choose the software as a user but not to
> not include them in Debian. We don't know how our users are going to use
> it and there might be use cases where those shortcomings are not
> problematic.

> We might want to document those shortcomings and in particular those that
> affect the network as a whole (backscatter) so that newcomers can avoid
> causing problems simply due to ignorance.

A goal of a distribution is to provide the best possible combination of
software and partly also do a selection for the users of what is good
and whatnot (by packaging it, supporting it in the distribution, etc).

>> - we do have many other, way more modern and better supported,
>>   MTAs available.
> Not a valid objection, we have way more window managers.

And having one WM in NEW that has the same other points like Qmail has
now, it would get the same refusal from our side. (Yet, a WM usually has
no problems like qmail that affect the whole net and not only a single
machine. Qmails mail behaviour fires back on everyone, no matter if they
use it or not).

>> - Still seems to violate the FHS. /var/lib/qmail/queue belongs into
>>   /var/spool, as far as we can tell.
> One more symlink in the package could resolve this. And I have seen
> numerous other packages that had similar problems but that have been
> accepted nevertheless. I don't think that it's a sufficient reason to
> reject the package. It's enougr to open a bug report against the package
> but not much more.

It is one, out of many, reasons.

>> - Lots of symlinks in /var/lib/qmail/bin going to /usr/bin/ and/or
>>   /usr/sbin. This is at least sick, if not again an FHS
>>   violation. var/lib is for "Variable state information", not binaries
>>   or links to them.
> Same thing than above, it's not nice but it's an effective way to comply
> with the FHS when upstream doesn't comply.

Dito.

--
bye, Joerg
<HE> Lalalala ... Ich bin die Sponsoren-Schlampe - Wer hat heute Lust?

[Kalle Kivimaa]

Raphael Hertzog <hertzog@...> writes:
> All those are good reasons to not choose the software as a user but not to
> not include them in Debian. We don't know how our users are going to use
> it and there might be use cases where those shortcomings are not
> problematic.

I think the more abstract question here is:

If a software easily causes problems for other machines in a network,
should that software be allowed into Debian, even if the software
doesn't bring any new functionality?

--
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*           PGP public key available @ http://www.iki.fi/killer           *


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Raphael Hertzog <hertzog@...> writes:
> On Thu, 01 Jan 2009, Joerg Jaspert wrote:

>> - several shortcomings related to the MTA behaviour, including the
>>   backscatter spam issue, failing to use secondary MXs, ignoring
>>   RFC1894, and unbundling of outgoing messages (yay for traffic/resource
>>   waste)[2], thus being unsupportably buggy (Policy 2.2.1)

> All those are good reasons to not choose the software as a user but not
> to not include them in Debian. We don't know how our users are going to
> use it and there might be use cases where those shortcomings are not
> problematic.

At this point, I think backscatter spam goes beyond buggy and into a
security issue.  It allows people to abuse your mail server to resend
spam.  Introducing a package into the archive with a known security issue
due to a design flaw that's unlikely to be fixed seems like something
worth thinking twice about.

Although maybe I'm wrong that it would be unlikely to be fixed.  There are
replacements for qmail-smtpd that do not have this problem --
qmail-qpsmtpd, for example.  A qmail package made with one of those
replacements would, to me, be a lot more compelling.

>> - still, in the reupload after the initial reject[3], seems to violate
>>   Policy (11.6), for example by not being able to handle etc/aliases
>>   files as required. Needs yet another package for this.
>>   Here qmail-run is the MTA provider, yet it doesn't follow the must in
>>   policy saying "All MTA packages must come with a newaliases program".
>>   Instead it has a recommends on fastforward, which then provides it.

> I'm don't know the rationale of this requirement in policy, adding aliases
> automatically is not really in the spirit of the policy that preserves
> configuration files.

/etc/aliases is something of a special case.  It's not owned by a package,
it's created by different mail-transport-agent packages, and other
postinst scripts do add aliases to it automatically (logcheck and
debarchiver, for example).

The rationale is that packages that provide mail-transport-agent need to
have a consistent interface.  This is as much for unbundled scripts and
tools, and for the system administrator, as it is for other Debian
packages.  It's a goal of Policy to dictate the required functionality and
interfaces of packages that satisfy primary virtual packages such as
mail-transport-agent.

> Anyway, changing the recommends to depends might be a solution.

Yes.

>> - qmail-uid-gid is creating users/gids with hardcoded ids in the
>>   60000-64999 range. While thats allowed from policy, stating "Globally
>>   allocated by the Debian project, but only created on demand.", wth is
>>   this global registry, and is qmail registered there?
>>   Also seems very much 18 century to have such hardcoded lists.

> Not sure about this one, some investigation needed.

The qmail user and group IDs are already registered.  See
/usr/share/doc/base-passwd/README.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ian Jackson]

Joerg Jaspert writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian"):
> Criteria that speak against inclusion:
> - no real upstream

I don't think that this is necessarily a showstopper.  We have many
important packages in Debian that have defunct or completely absent
upstreams, so that in some cases the Debian maintainer has become de
facto upstream not just for Debian but for many other systems too.

What is required is that _someone_ is able and prepared to act as
upstream.  Is Gerrit Pape willing and able to do that ?  Does he have
the skills and experience necessary for maintaining an MTA package
written in a somewhat-strange C dialect ?  (I haven't looked into this
question but it seems the one we need to ask.)

This may seem like an unfair argument but I think it's valid: I think
that if someone is so keen on Qmail that they want to add it to Debian,
that in itself might well lead us to question their competence to deal
with Internet email systems.

> - several shortcomings related to the MTA behaviour, including the
>   backscatter spam issue, failing to use secondary MXs, ignoring
>   RFC1894, and unbundling of outgoing messages (yay for traffic/resource
>   waste)[2], thus being unsupportably buggy (Policy 2.2.1)

Most of these are IMO release-critical bugs.  Qmail's aberrant
behaviours are well-known in the Internet mail community.  They are in
many cases gross violations of reasonable and acceptable behaviour and
can cause serious problems for other sites as well as the Qmail
administrator.

So we absolutely MUST NOT provide such a Qmail.

It is possible for a new package with release-critical bugs to belong
in sid.  However, this only makes sense as part of a plan to address
these bugs and fix them so that the package can propagate to testing
and only if the bugs are not absolutely hideous (and some of these
are).

Such a plan does not IMO need to be a sure thing, but it needs to have
a reasonable prospect of success.  That's very difficult for
deficiences which are built into the design.

So at the minimum I would expect an explanation from the prospective
maintainer.  Gerrit, can you supply a list of:
  * Every criticism which (otherwise-) reasonable people have
    levelled as a serious complaint against Qmail (and I don't
    include just the complaints made by the ftpmasters);
  * For each such criticism, what your opinion of it is and what
    if anything you plan to do about it.

> - still, in the reupload after the initial reject[3], seems to violate
>   [etc. etc. -iwj]

More bugs, generally RC IMO.  (Although I don't want to go into them
in detail.)

> - we do have many other, way more modern and better supported,
>   MTAs available.
>
> - The already existing (in non-free) qmail-src package only counts
>   238 installations, which doesn't seem to imply a large userbase.

These are of course not in themselves reasons not to accept a package,
or at least if they are they are very weak.  But it does mean that
there is no need here for thinking very hard about making exceptions
if it seems that Qmail is just too bad.

Ian.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ian Jackson]

Raphael Hertzog writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian"):
> On Thu, 01 Jan 2009, Joerg Jaspert wrote:
> > Yet, we do see that there are people who want Qmail, and instead of
> > maintaining it in an own repository want it in Debian. As it is unlikely
> > that the positions of the Qmail supporters and us will change soon to
> > let us find a solution that works for both sides (the positions are
> > basically black and white here), we ask you to help resolve it,
> > by a ruling on this matter, following Constitution §6.1.3.
>
> What constitutes for you a solution that works for both sides?  

I think you have misread Joerg.  I did the same at first.  Joerg is
saying that he thinks that there is _not_ any sensible compromise and
_not_ anything that will work for both sides.

I think I agree but of course I'm open to suggestions.

> Gerrit is not available until end of january so it seems rather badly
> timed to bring this request forward now giving no chance to Gerrit to
> give his arguments.

I think for this reason we should wait until Gerrit has a chance to
respond to these emails.  In the meantime the ftpmaster's decision
should stand, clearly.

> > - several shortcomings related to the MTA behaviour, including the
> >   backscatter spam issue, failing to use secondary MXs, ignoring
> >   RFC1894, and unbundling of outgoing messages (yay for traffic/resource
> >   waste)[2], thus being unsupportably buggy (Policy 2.2.1)
>
> All those are good reasons to not choose the software as a user but not to
> not include them in Debian. We don't know how our users are going to use
> it and there might be use cases where those shortcomings are not
> problematic.

I think this is a dangerous line of argument.  Many of Qmail's
behaviours are terrible in the global Internet and we have no
effective way to prevent (or even warn) our users from running Qmail
in that situation.

Indeed practically the only reason why people want Qmail is because
they believe the hype about how ultra secure it is - which is relevant
(if you believe it) in precisely the circumstances where Qmail's
problems are most severe.


Joerg Jaspert writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian"):
> [Raphael:]
> > Why "no real"? Did Gerrit commit to something?
>
> DJB isn't doing it. Some others seem to maintain some set of patches.

Is there anything resembling an upstream maintenance community - a
mailing list they all use or something ?  I'd be interested to see its
archives.


Kalle Kivimaa writes ("Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian"):
> I think the more abstract question here is:
>
> If a software easily causes problems for other machines in a network,
> should that software be allowed into Debian, even if the software
> doesn't bring any new functionality?

Yes, I think that's an excellent way to put the question.  The answer
is obviously `no'.

Either steps need to be taken to prevent these problems (for the
network as a whole, for other parts of Debian who need to interact
with the package, and for the user who runs it) - or the package
should not be included.


Ian.


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Don Armstrong]

On Thu, 01 Jan 2009, Joerg Jaspert wrote:
> Yet, we do see that there are people who want Qmail, and instead of
> maintaining it in an own repository want it in Debian. As it is
> unlikely that the positions of the Qmail supporters and us will
> change soon to let us find a solution that works for both sides (the
> positions are basically black and white here), we ask you to help
> resolve it, by a ruling on this matter, following Constitution
> §6.1.3.

Would

      1) an upload to experimental with
      2) all of the issues that have been identified as RC filed as RC
         bugs against the package with
      3) acceptance into sid occuring only when the RC bugs which have
         a serious negative impact on the internet in large fixed and
      4) acceptance into testingg occuring as usual with
      5) an RM "unacceptable for release" RC bug filed until the RMs
         have a chance to come to a determination

be an acceptable compromise for the ftpmasters and the prospective
Qmail maintainer(s)? (Or at least, a start towards something that
could possibly be compromised on?)

As much as I'm not a fan of Qmail, I don't think the project should
stand in the way if someone is actually interested in spending the
time to attempt to make it acceptable for eventual release.

I don't think there's a reason a priori that we can say that Qmail
will never be acceptable for release, and we have means of allowing it
into the archive, but blocking it from eventual release using the
"RM(s) finds a package unaccpetable for release" serious bug in
addition to other actual bugs in the package. It'd also enable the
people who want to work on Qmail to have access to the project
resources so that if a package ever is close to acceptable for
inclusion, there won't be any need to figure out again the problems
that Qmail has.


Don Armstrong

--
Whatever you do will be insignificant, but it is very important that
you do it.
 -- Mohandas Karamchand Gandhi

http://www.donarmstrong.com              http://rzlab.ucr.edu



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

On Mon, 05 Jan 2009, Don Armstrong wrote:

> Would
>
>       1) an upload to experimental with
>       2) all of the issues that have been identified as RC filed as RC
>          bugs against the package with
>       3) acceptance into sid occuring only when the RC bugs which have
>          a serious negative impact on the internet in large fixed and
>       4) acceptance into testingg occuring as usual with
>       5) an RM "unacceptable for release" RC bug filed until the RMs
>          have a chance to come to a determination
>
> be an acceptable compromise for the ftpmasters and the prospective
> Qmail maintainer(s)? (Or at least, a start towards something that
> could possibly be compromised on?)

+1.

I find this suggestion to be much more in line with our current
procedures.

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 saying that we must let any crap enter the archive but when we
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.

> As much as I'm not a fan of Qmail, I don't think the project should
> stand in the way if someone is actually interested in spending the
> time to attempt to make it acceptable for eventual release.

Agreed. Same here.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Kalle Kivimaa]

Raphael Hertzog <hertzog@...> writes:
> 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.

Well, I personally am against the Qmail in Debian at it's current
state because I consider it to have at least one critical security bug
and several other RC bugs, and I don't see how to solve the critical
bug without a serious rewrite. If somebody manages to solve those bugs
(and fix the other policy issues), then I'd have much less incentive
to reject Qmail.

I don't see the arguments we've made as difficult to justify. If we
felt that we couldn't justify them, we wouldn't have made them in the
first place and grudginly accepted the package.

>> As much as I'm not a fan of Qmail, I don't think the project should
> Agreed. Same here.

Actually, I *am* a fan of Qmail, but I think it is outdated in today's
internet, and anybody considering to use it as a MTA should think very
hard of the pros and cons.

--
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*           PGP public key available @ http://www.iki.fi/killer           *


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

On Tue, 06 Jan 2009, Ian Jackson wrote:

> Raphael Hertzog writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian"):
> > On Thu, 01 Jan 2009, Joerg Jaspert wrote:
> > > Yet, we do see that there are people who want Qmail, and instead of
> > > maintaining it in an own repository want it in Debian. As it is unlikely
> > > that the positions of the Qmail supporters and us will change soon to
> > > let us find a solution that works for both sides (the positions are
> > > basically black and white here), we ask you to help resolve it,
> > > by a ruling on this matter, following Constitution §6.1.3.
> >
> > What constitutes for you a solution that works for both sides?  
>
> I think you have misread Joerg.  I did the same at first.  Joerg is
> saying that he thinks that there is _not_ any sensible compromise and
> _not_ anything that will work for both sides.

Indeed I did.

> > > - several shortcomings related to the MTA behaviour, including the
> > >   backscatter spam issue, failing to use secondary MXs, ignoring
> > >   RFC1894, and unbundling of outgoing messages (yay for traffic/resource
> > >   waste)[2], thus being unsupportably buggy (Policy 2.2.1)
> >
> > All those are good reasons to not choose the software as a user but not to
> > not include them in Debian. We don't know how our users are going to use
> > it and there might be use cases where those shortcomings are not
> > problematic.
>
> I think this is a dangerous line of argument.  Many of Qmail's
> behaviours are terrible in the global Internet and we have no
> effective way to prevent (or even warn) our users from running Qmail
> in that situation.

We do have ways to warn users of the package. We can, for example, add an
annoying debconf note to explain the problems of qmail and point them to
some documentation provided in the package.

> Indeed practically the only reason why people want Qmail is because
> they believe the hype about how ultra secure it is - which is relevant
> (if you believe it) in precisely the circumstances where Qmail's
> problems are most severe.

When Debian was running it on lists.debian.org, it was primarily for
performance reasons IIRC (a listmaster of that time can correct me). It
might be that it's no more the selling factor nowadays, but I find it
presomptuous to believe to know why users are interested in it, without
some more serious study.

> Kalle Kivimaa writes ("Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian"):
> > I think the more abstract question here is:
> >
> > If a software easily causes problems for other machines in a network,
> > should that software be allowed into Debian, even if the software
> > doesn't bring any new functionality?
>
> Yes, I think that's an excellent way to put the question.  The answer
> is obviously `no'.

I don't think the answer is so clear cut. "ping -f" can also "easily
causes problems for other machines in a network".

I know we're speaking of the default configuration of a mail daemon
and that the comparison doesn't really hold (although it does with the
phrasing selected).

My main problem is that not including the software in Debian doesn't give
any chance to improve in our infrastructure and that the ftpmasters is not
the right body to decide on the quality of a package (see below), except
for some limited policy compliance check.

> Either steps need to be taken to prevent these problems (for the
> network as a whole, for other parts of Debian who need to interact
> with the package, and for the user who runs it) - or the package
> should not be included.

I can buy this reasoning when it comes to inclusion in a stable release
but not for inclusion in experimental (or sid if the proper RC bugs are
filed immediately).

It's very similar to the reportbug-ng problems that explain that the software
is not part of Lenny.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Joerg Jaspert]

>> Indeed practically the only reason why people want Qmail is because
>> they believe the hype about how ultra secure it is - which is relevant
>> (if you believe it) in precisely the circumstances where Qmail's
>> problems are most severe.
> When Debian was running it on lists.debian.org, it was primarily for
> performance reasons IIRC (a listmaster of that time can correct me). It
> might be that it's no more the selling factor nowadays, but I find it
> presomptuous to believe to know why users are interested in it, without
> some more serious study.

That (performance is good with qmail) is untrue for a long time. In fact
it was and is slower than others.
Im not a listmaster and havent been one back then, but from what I
remember from IRC and discussion, at the time Debian switched away from
qmail, the new system, postfix, was an order of magnitude faster than qmail.

>From an IRC discussion I had last year with a DSA member that was
involved in changing the lists setup, it was
"exim more configurable, but unable to do the volume that lists did at
that time, on that hardware. And postfix was even way faster".
And if one thinks back, that was a (now) stone-age postfix...

--
bye, Joerg
You're in good shape for being a Debian, with a SAP background
... anything has to look good from there...


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Don Armstrong]

On Tue, 06 Jan 2009, Kalle Kivimaa wrote:
> Well, I personally am against the Qmail in Debian at it's current
> state because I consider it to have at least one critical security
> bug and several other RC bugs, and I don't see how to solve the
> critical bug without a serious rewrite.

I agree that Qmail has lots of bugs some of which are critical for the
health of the internet at large, and I think it needs a period in
experimental to get those bugs resolved.

That said, the serious problems that it has are problems that are
present in the qmail-src packages, IIUC. The ideal end state is a
Qmail package that resolves all of these problems, and it'd be better
to have such a package than our current state.

> I don't see the arguments we've made as difficult to justify. If we
> felt that we couldn't justify them, we wouldn't have made them in
> the first place and grudginly accepted the package.

I agree with the arguments about the problems with the package; I'm
just slightly concerned about the method with which they are dealt
with.
 
> Actually, I *am* a fan of Qmail, but I think it is outdated in
> today's internet, and anybody considering to use it as a MTA should
> think very hard of the pros and cons.

I agree as well; that said, if someone in Debian wants to put in the
work to make Qmail have more pros than cons so those people who are
going to run Qmail anyway can do so without bothering the rest of us,
more power to htem.


Don Armstrong

--
If a nation values anything more than freedom, it will lose its
freedom; and the irony of it is that if it is comfort or money it
values more, it will lose that, too.
 -- W. Somerset Maugham

http://www.donarmstrong.com              http://rzlab.ucr.edu



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ian Jackson]

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.

This is no different to any developer deciding what's acceptable in
their package according to some `non-usual policy requirements that
can be difficult to justify'.

Ian.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Barth]

Hi,

as the submitter was whining why only one member of the tech ctte commented so
far, I'll comment as well:

* Ian Jackson (ian@...) [090106 02:02]:
> Raphael Hertzog writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian"):
> > Gerrit is not available until end of january so it seems rather badly
> > timed to bring this request forward now giving no chance to Gerrit to
> > give his arguments.
>
> I think for this reason we should wait until Gerrit has a chance to
> respond to these emails.  In the meantime the ftpmaster's decision
> should stand, clearly.

Agreeing to that (and the remaining parts of the mail), so waiting for comments
from Gerrit (and other people who can answer Ian's questions).


Cheers,
Andi


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steve Langasek]

On Tue, Jan 06, 2009 at 08:48:08AM +0100, Raphael Hertzog wrote:
> On Mon, 05 Jan 2009, Don Armstrong wrote:

> >       1) an upload to experimental with
> >       2) all of the issues that have been identified as RC filed as RC
> >          bugs against the package with
> >       3) acceptance into sid occuring only when the RC bugs which have
> >          a serious negative impact on the internet in large fixed and
> >       4) acceptance into testingg occuring as usual with
> >       5) an RM "unacceptable for release" RC bug filed until the RMs
> >          have a chance to come to a determination

> > be an acceptable compromise for the ftpmasters and the prospective
> > Qmail maintainer(s)? (Or at least, a start towards something that
> > could possibly be compromised on?)

> +1.

> I find this suggestion to be much more in line with our current
> procedures.

> 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.

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.

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'm not saying that we must let any crap enter the archive but when we
> 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.

(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.)

--
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@...                                     vorlon@...



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

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/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ian Jackson]

(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.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

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/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bdale Garbee]

On Fri, 2009-01-09 at 09:33 +0100, Raphael Hertzog wrote:

> 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).

The way I look at this is that it has not been a primary *expectation*
of the project that the ftpmasters review and approve the quality of the
software that is packaged.  The lack of a routine expectation does and
should not prevent them doing it, however.

> Yes. But there are limits on their responsibilities.

> > 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'm with Ian on this aspect.  We limit our expectations, which sets the
lower bound on what the ftpmasters are expected to do.  And we have
checks and balances as a consequence of their delegated status that set
the upper bound on what the ftpmasters should do.  In between, we grant
them broad discretion to do their work.

> 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.

It certainly doesn't seem like a reasonable response given the obvious
alternative of working on the issues identified to improve the software.

Bdale




--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...