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

Package: tech-ctte; Maintainer for tech-ctte is Technical Committee <debian-ctte@lists.debian.org>;

Reported by: Joerg Jaspert <joerg@debian.org>

Date: Thu, 1 Jan 2009 16:48:02 UTC

Severity: normal

Done: Don Armstrong <don@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Joerg Jaspert <joerg@debian.org>, Gerrit Pape <pape@smarden.org>, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Thu, 01 Jan 2009 16:48:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joerg Jaspert <joerg@debian.org>:
New Bug report received and forwarded. Copy sent to Joerg Jaspert <joerg@debian.org>, Gerrit Pape <pape@smarden.org>, Technical Committee <debian-ctte@lists.debian.org>. (Thu, 01 Jan 2009 16:48:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Joerg Jaspert <joerg@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: tech-ctte: Qmail inclusion (or not) in Debian
Date: Thu, 01 Jan 2009 17:46:08 +0100
[Message part 1 (text/plain, inline)]
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? :) )
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Fri, 02 Jan 2009 13:51:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 02 Jan 2009 13:51:02 GMT) Full text and rfc822 format available.

Message #10 received at 510415@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Joerg Jaspert <joerg@debian.org>, 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 2 Jan 2009 14:49:22 +0100
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/




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Fri, 02 Jan 2009 15:18:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joerg Jaspert <joerg@ganneff.de>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 02 Jan 2009 15:18:05 GMT) Full text and rfc822 format available.

Message #15 received at 510415@bugs.debian.org (full text, mbox):

From: Joerg Jaspert <joerg@ganneff.de>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 02 Jan 2009 16:14:57 +0100
[Message part 1 (text/plain, inline)]
>> (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?
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Fri, 02 Jan 2009 18:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 02 Jan 2009 18:18:02 GMT) Full text and rfc822 format available.

Message #20 received at 510415@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 02 Jan 2009 10:14:45 -0800
Raphael Hertzog <hertzog@debian.org> 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@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Tue, 06 Jan 2009 00:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 06 Jan 2009 00:42:03 GMT) Full text and rfc822 format available.

Message #25 received at 510415@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Joerg Jaspert <joerg@debian.org>, 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Tue, 6 Jan 2009 00:38:11 +0000
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.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Tue, 06 Jan 2009 01:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 06 Jan 2009 01:18:02 GMT) Full text and rfc822 format available.

Message #30 received at 510415@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: 510415@bugs.debian.org, Joerg Jaspert <joerg@ganneff.de>, Kalle Kivimaa <killer@debian.org>
Cc: Joerg Jaspert <joerg@debian.org>, debian-ctte@lists.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Tue, 6 Jan 2009 01:15:51 +0000
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.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Tue, 06 Jan 2009 01:36:07 GMT) Full text and rfc822 format available.

Message #33 received at 510415@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Mon, 5 Jan 2009 17:35:42 -0800
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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Tue, 06 Jan 2009 07:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 06 Jan 2009 07:51:06 GMT) Full text and rfc822 format available.

Message #38 received at 510415@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Tue, 6 Jan 2009 08:48:08 +0100
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/




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Tue, 06 Jan 2009 08:15:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 06 Jan 2009 08:15:02 GMT) Full text and rfc822 format available.

Message #43 received at 510415@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: 510415@bugs.debian.org
Cc: Joerg Jaspert <joerg@ganneff.de>, Ian Jackson <ian@davenant.greenend.org.uk>
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Tue, 6 Jan 2009 09:12:53 +0100
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/




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Tue, 06 Jan 2009 09:06:06 GMT) Full text and rfc822 format available.

Message #46 received at 510415@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Tue, 6 Jan 2009 01:02:35 -0800
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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Tue, 06 Jan 2009 20:24:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 06 Jan 2009 20:24:06 GMT) Full text and rfc822 format available.

Message #51 received at 510415@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Tue, 6 Jan 2009 20:22:47 +0000
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.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Wed, 07 Jan 2009 00:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 07 Jan 2009 00:03:02 GMT) Full text and rfc822 format available.

Message #56 received at 510415@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: debian-ctte@lists.debian.org
Cc: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Wed, 7 Jan 2009 00:44:42 +0100
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@davenant.greenend.org.uk) [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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Wed, 07 Jan 2009 01:57:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 07 Jan 2009 01:57:05 GMT) Full text and rfc822 format available.

Message #61 received at 510415@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Raphael Hertzog <hertzog@debian.org>, 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Tue, 6 Jan 2009 17:53:29 -0800
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@ubuntu.com                                     vorlon@debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Wed, 07 Jan 2009 07:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 07 Jan 2009 07:57:02 GMT) Full text and rfc822 format available.

Message #66 received at 510415@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Wed, 7 Jan 2009 08:53:24 +0100
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/




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Thu, 08 Jan 2009 20:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 08 Jan 2009 20:03:03 GMT) Full text and rfc822 format available.

Message #71 received at 510415@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Thu, 8 Jan 2009 20:00:41 +0000
(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.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Fri, 09 Jan 2009 08:36:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 09 Jan 2009 08:36:04 GMT) Full text and rfc822 format available.

Message #76 received at 510415@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Ian Jackson <ian@davenant.greenend.org.uk>, 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 9 Jan 2009 09:33:50 +0100
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/




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Fri, 09 Jan 2009 14:48:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bdale Garbee <bdale@gag.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 09 Jan 2009 14:48:03 GMT) Full text and rfc822 format available.

Message #81 received at 510415@bugs.debian.org (full text, mbox):

From: Bdale Garbee <bdale@gag.com>
To: Raphael Hertzog <hertzog@debian.org>, 510415@bugs.debian.org
Cc: Ian Jackson <ian@davenant.greenend.org.uk>
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 09 Jan 2009 07:46:08 -0700
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





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Fri, 09 Jan 2009 23:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 09 Jan 2009 23:54:03 GMT) Full text and rfc822 format available.

Message #86 received at 510415@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Joerg Jaspert <joerg@debian.org>, 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 9 Jan 2009 15:52:23 -0800
I know we're still waiting for Gerrit to be available before proceding much
further with this, but I wanted to lay out my own point-by-point analysis of
the reasons given for rejection to help us start to work out what the
current consensus is regarding which issues should or shouldn't be blockers.

On Thu, Jan 01, 2009 at 05:46:08PM +0100, Joerg Jaspert wrote:
> Criteria that speak against inclusion:
> - no real upstream

Neither necessary nor sufficient to block the package over the wishes of the
uploader.

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

Can you expand here on the consequences of ignoring RFC1894?  I'm aware that
qmail delivery failure mails look different (and, I might argue,
gratuitously so) than those of other mail systems, but does this cause
interoperability problems for other Internet users?

The backscatter spam issue is, IMHO, sufficient reason to block this package
from being accepted into the archive.  Debian should not be in the position
of facilitating the deployment of servers that are "bad citizens" on the
Internet.

The other issues are reasons not to use qmail, but I don't think they're
grounds to keep it out of the archive.

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

Neither necessary nor sufficient to block the package over the wishes of the
uploader.

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

Policy is clear on this point, and I think it's appropriate for the ftp team
to treat this as a blocker for archive acceptance.  This is a serious policy
violation for a couple of different, *practical*, reasons:

- If the package which contains the newaliases command is not the package
  which Provides: m-t-a, then the Conflicts/Replaces: m-t-a of all other MTA
  packages will fail to match here and will result in dpkg file conflict
  errors.  It is not reasonable to ask all other MTA packages to Conflict:
  m-t-a, fastforward in response to this.  (Cf. the discussions on
  debian-devel in early/mid 2008 regarding creation of a "default-m-t-a"
  package.)
- If the package which Provides: m-t-a neither contains nor depends on a
  package containing /usr/bin/newaliases, then the interface specified by
  Policy is not guaranteed to be available, so packages which Depend:
  mail-transport-agent may fail despite having their dependencies satisfied.

Serious policy violations are, IMHO, sufficient reason to block a package
from reaching the archive.  Doubly so if the maintainer appears to be
unwilling to resolve them.

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

Looking at the FHS, I see no indication that the mail queue is required to
be located under /var/spool, and the distinction between "spool data" and
"variable state information" is a fuzzy and debatable one.  So I don't think
this is a policy violation, and therefore it shouldn't block inclusion in
the archive.

I would still certainly *encourage* the maintainer to evaluate whether
/var/spool would be a better location for this data.  One of the values of
the FHS is in providing a clear heirarchical structure that can be used as
the basis for a generic backup policy, or for provisioning disks/filesystems
with different performance characteristics.  Adhering to the FHS has
practical benefits.

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

It is a violation of Policy's requirements regarding the FHS.

9.1.1. File system Structure
----------------------------

     The location of all installed files and directories must comply with
     the File system Hierarchy Standard (FHS), version 2.3, with the
     exceptions noted below, and except where doing so would violate other
     terms of Debian Policy. 

The files must be installed in /usr, not just symlinked from /usr.

This is a much more clear-cut violation of the FHS than the spool/lib
question, and I think it's reasonable to block a package from main that
misuses /usr vs. /var.  Practical consequences here: having to store more
files on a filesystem that must be mounted read-write during normal
operation, marginally increasing the risk of fs corruption and possibly
consuming scarce writable media in some system configurations (embedded
systems?); requiring more complex MAC rules on SELinux et al.

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

As noted elsewhere in the thread, this is entirely compliant with policy
and should absolutely not be grounds for exclusion from the archive.

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

Neither necessary nor sufficient to block the package over the wishes of the
uploader.

Cheers,
-- 
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@ubuntu.com                                     vorlon@debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sat, 10 Jan 2009 01:06:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 10 Jan 2009 01:06:02 GMT) Full text and rfc822 format available.

Message #91 received at 510415@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Raphael Hertzog <hertzog@debian.org>, 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 9 Jan 2009 17:03:09 -0800
On Wed, Jan 07, 2009 at 08:53:24AM +0100, Raphael Hertzog wrote:
> > 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".

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

I happen to disagree that the ftp team's current standards of bugginess are
appropriate, because they're taking liberties to set standards that don't
follow from Debian Policy - but that's a separate question, and doesn't lead
me to a different conclusion than the one they've reached regarding the
current qmail package.

> In fact, I tend to think that Qmail is special-cased because it's popular
> and the problems are well known. 

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
expect the ftp team to bring all their expertise to bear when making
decisions about what belongs in the archive.

(If an ftp team member had independent knowledge that a package violated
copyright law, should he ignore this fact and make a determination based
only on the debian/copyright file?)

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

I would be happy to see a group of interested developers provide the same
level of scrutiny to other NEW packages that don't have such a high profile,
to determine whether they're also fundamentally dangerous to include in the
archive.  But a) we shouldn't block packages in NEW while waiting for such
volunteer resources to materialize, and b) packages that have known problems
shouldn't be allowed into the archive due to some misguided concept of
"fairness".

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

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.

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

This is an interesting claim that gives me pause for thought.  I'm not sure
that it's true, but I also don't know of any specific counterexamples.

Regardless, while it's interesting to consider whether there is precedent, I
don't think this changes my opinion that allowing software into main is an
area of shared authority between the maintainer and the ftp-team.

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

Note that several of the issues that I consider blockers for the package's
acceptance into the archive are codified in Policy, which is where we as a
project get our definition of software that's "too buggy to live".

Issues that are not Policy violations - i.e., grave and critical bugs - are
currently defined/handled ad hoc, by a combination of the ftp team, the
debbugs team, the release team, and the QA team.  I think grave/critical
bugs are equally valid reasons to reject packages out of NEW, but you're
right that there's no clear path by which the authority to reject these
packages flows from the project to the ftp team.

We as a project should correct this - which I think means getting the DPL to
make an explicit delegation of the power to block packages from the archive
that fail our traditional grave/critical bug criteria.

-- 
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@ubuntu.com                                     vorlon@debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sat, 10 Jan 2009 01:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 10 Jan 2009 01:18:03 GMT) Full text and rfc822 format available.

Message #96 received at 510415@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 9 Jan 2009 17:15:50 -0800
On Fri, Jan 09, 2009 at 09:33:50AM +0100, Raphael Hertzog wrote:
> 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.

I generally agree with this, except that I think the ftp team should have
the discretion to reject packages for bugs that qualify as grave or
critical.

-- 
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@ubuntu.com                                     vorlon@debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sat, 10 Jan 2009 02:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 10 Jan 2009 02:45:03 GMT) Full text and rfc822 format available.

Message #101 received at 510415@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 09 Jan 2009 18:41:55 -0800
Steve Langasek <vorlon@debian.org> writes:
> On Fri, Jan 09, 2009 at 09:33:50AM +0100, Raphael Hertzog wrote:

>> We all know how NEW processing regularly result in complaints.

Telling people "no" results in complaints.  Unless we're saying that we
shouldn't ever tell people no on accepting packages, I don't think this is
an argument for moving this function from NEW processing to somewhere
else.  It just moves the complaints.

>> Trying to enhance the policy to be more fair could help.

It's going to be difficult to be fair across all packages in the archive
just because the ftp team will miss things.  But when they do notice
things, I think they should do something about them.  I'd rather not
sacrifice what review they have time to do because we can't do it for all
packages.

If the wrong criteria are being applied, that's a separate problem, but
out of the overall volume of packages and rejects, I don't think that's a
serious problem.  There is the occasional package where the maintainer
gets upset, but it's fairly rare.

>> IMO the quality issues that are not covered by an explicit policy point
>> should result in bugs being filed and not in package rejects.
>
> I generally agree with this, except that I think the ftp team should
> have the discretion to reject packages for bugs that qualify as grave or
> critical.

I'm with Steve on this.  I think the ftp team review is valuable, and as a
project it takes us much more effort to deal with critically buggy
packages after they're in the archive than before they get there.

All of the teams who have to deal with critically buggy packages once
they're in the archive are chronically understaffed.  If the packages
aren't accepted in the first place, fixing the bugginess is the problem of
the person who wants to upload them.  After they're accepted into the
archive, in practice dealing with it often becomes the problem of a lot of
other people who have other critical tasks.  Overall, I think an ftp team
reject is a fairly good tradeoff unless they're frequently wrong, and I
haven't gotten the impression that they are.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sat, 10 Jan 2009 08:57:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 10 Jan 2009 08:57:01 GMT) Full text and rfc822 format available.

Message #106 received at 510415@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Russ Allbery <rra@debian.org>, 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sat, 10 Jan 2009 09:53:03 +0100
Hi,

On Fri, 09 Jan 2009, Russ Allbery wrote:
> I'm with Steve on this.  I think the ftp team review is valuable, and as a
> project it takes us much more effort to deal with critically buggy
> packages after they're in the archive than before they get there.
> 
> All of the teams who have to deal with critically buggy packages once
> they're in the archive are chronically understaffed.

What are those teams? I can only think of the security team that has a
duty to support the security of the stable release. And even this team has
now some (widely unknown) way to say that they don't fully support some
specific packages (they do that with a specific tag in debtag).

And in the case of Qmail, the security team said that they have no
probleme supporting it.

> If the packages aren't accepted in the first place, fixing the bugginess
> is the problem of the person who wants to upload them.  After they're
> accepted into the archive, in practice dealing with it often becomes the
> problem of a lot of other people who have other critical tasks.
> Overall, I think an ftp team reject is a fairly good tradeoff unless
> they're frequently wrong, and I haven't gotten the impression that they
> are.

Would it make sense to have an "unsupported" dist where packages can
not be auto-transitioned by the maintainer to sid ?

So that we have a place for such packages without imposing any duty on
Debian as a whole and so that we leave a real chance for motivated
maintainer to enhance them within Debian. It would be a bit like the
"staging" area in the Linux kernel.

Cheers,
-- 
Raphaël Hertzog

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sat, 10 Jan 2009 09:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 10 Jan 2009 09:09:14 GMT) Full text and rfc822 format available.

Message #111 received at 510415@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Steve Langasek <vorlon@debian.org>, 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sat, 10 Jan 2009 10:02:59 +0100
On Fri, 09 Jan 2009, Steve Langasek wrote:
> I know we're still waiting for Gerrit to be available before proceding much
> further with this, but I wanted to lay out my own point-by-point analysis of
> the reasons given for rejection to help us start to work out what the
> current consensus is regarding which issues should or shouldn't be blockers.

I agree with everything you said except one point you misunderstood IMO:

> > - 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.
> 
> It is a violation of Policy's requirements regarding the FHS.
> 
> 9.1.1. File system Structure
> ----------------------------
> 
>      The location of all installed files and directories must comply with
>      the File system Hierarchy Standard (FHS), version 2.3, with the
>      exceptions noted below, and except where doing so would violate other
>      terms of Debian Policy. 
> 
> The files must be installed in /usr, not just symlinked from /usr.

I understood that they are installed in /usr but that symlinks are
installed in /var, probably because Qmail expect them to be below
/var/lib/qmail.

While not nice and ideal, I believe it's an acceptable compromise if
upstream doesn't want to fix the software to look in different
directories.

A quick check on the package confirms this:
lrwxrwxrwx root/root         0 2008-08-28 15:23 ./var/lib/qmail/bin/qmail-inject -> /usr/bin
/qmail-inject

Cheers,
-- 
Raphaël Hertzog

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sat, 10 Jan 2009 14:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 10 Jan 2009 14:48:03 GMT) Full text and rfc822 format available.

Message #116 received at 510415@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sat, 10 Jan 2009 06:46:31 -0800
Luk Claes <luk@debian.org> writes:
> Raphael Hertzog wrote:

>> What are those teams? I can only think of the security team that has a
>> duty to support the security of the stable release. And even this team
>> has now some (widely unknown) way to say that they don't fully support
>> some specific packages (they do that with a specific tag in debtag).

> There is the QA Team, the Release Teams and the Security Team at least.

Yes.  Plus anyone who looks at RC bugs, although if the package isn't in
testing, it gets filtered out of the more critical lists.  There are also
the buildd maintainers and porters, depending on the nature of the bug.

Once a package makes it into Debian, we do a fairly good job at taking
collective responsbility for dealing with it.  I think this is one of the
strengths of Debian, but it does mean that uploading a package is an act
that doesn't only affect the maintainer.  It places some implicit demands
on other people's time as well.

> The code might be security supportable, but still not easy to integrate
> in a distribution nor have the quality expected to be in a release. I do
> think packages which don't qualify for inclusion in the release because
> of quality issues should be able to be uploaded to the archive, though
> only when there is a high chance that these quality issues (including
> integration issues) will be solved.

That sounds right to me too.

>> Would it make sense to have an "unsupported" dist where packages can
>> not be auto-transitioned by the maintainer to sid ?

> We have experimental, though there is nothing in effect that prevents a
> maintainer to upload experimental packages to unstable atm...

Packages only in experimental are ignored by Release and Security, so that
would address part of my concern.  (And I expect QA to mostly ignore them
as well unless nothing appears to be happening with them.)

I like the idea mentioned earlier in this bug of using experimental as a
place to put a package with known issues while those issues are tracked as
a compromise.  I think a reject is better as a general policy for most
packages, but for controversial cases, using experimental to see if the
bugs really will be fixed may be a good idea.

>> So that we have a place for such packages without imposing any duty on
>> Debian as a whole and so that we leave a real chance for motivated
>> maintainer to enhance them within Debian. It would be a bit like the
>> "staging" area in the Linux kernel.

> Whatever staging area you have within Debian, it will be a suite so FTP
> Master will be involved and the QA Team would (should) make sure
> unspotted cruft gets noticed...

I think our collective responsibility for packages is a feature, not a
bug, so I'm not particularly thrilled by the idea of having an official
area in the project that doesn't imply some level of collective
responsibility.  It's trivial to create a personal Debian repository, and
people already use that to distribute and test packages that shouldn't
place any obligations on the rest of Debian.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sat, 10 Jan 2009 15:39:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 10 Jan 2009 15:39:02 GMT) Full text and rfc822 format available.

Message #121 received at 510415@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sat, 10 Jan 2009 16:35:59 +0100
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?

2. 

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
secteam::lenny-limited-support.

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

Cheers,
-- 
Raphaël Hertzog

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sat, 10 Jan 2009 19:12:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 10 Jan 2009 19:12:08 GMT) Full text and rfc822 format available.

Message #126 received at 510415@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sat, 10 Jan 2009 11:10:02 -0800
On Sat, Jan 10, 2009 at 10:02:59AM +0100, Raphael Hertzog wrote:
> > > - 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.

> > It is a violation of Policy's requirements regarding the FHS.

> > 9.1.1. File system Structure
> > ----------------------------

> >      The location of all installed files and directories must comply with
> >      the File system Hierarchy Standard (FHS), version 2.3, with the
> >      exceptions noted below, and except where doing so would violate other
> >      terms of Debian Policy. 

> > The files must be installed in /usr, not just symlinked from /usr.

> I understood that they are installed in /usr but that symlinks are
> installed in /var, probably because Qmail expect them to be below
> /var/lib/qmail.

> While not nice and ideal, I believe it's an acceptable compromise if
> upstream doesn't want to fix the software to look in different
> directories.

> A quick check on the package confirms this:
> lrwxrwxrwx root/root         0 2008-08-28 15:23 ./var/lib/qmail/bin/qmail-inject -> /usr/bin
> /qmail-inject

Ok.  I think technically that's still a violation (at least in an earlier
version of the FHS there was wording to the effect that an FHS-compliant
application had to use only the FHS directories when accessing files), but
it's one with fewer practical implications, so I don't think that should
block a package from the archive.

-- 
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@ubuntu.com                                     vorlon@debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sun, 11 Jan 2009 11:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kalle Kivimaa <killer@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 11 Jan 2009 11:03:02 GMT) Full text and rfc822 format available.

Message #131 received at 510415@bugs.debian.org (full text, mbox):

From: Kalle Kivimaa <killer@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sun, 11 Jan 2009 12:59:50 +0200
Steve Langasek <vorlon@debian.org> writes:
> Can you expand here on the consequences of ignoring RFC1894?  I'm aware that
> qmail delivery failure mails look different (and, I might argue,
> gratuitously so) than those of other mail systems, but does this cause
> interoperability problems for other Internet users?

RFC1894 ignorance produces at least these problems for
interoperability in Internet:

- Translation of the error messages fails
- Mailing list software fails to parse the error message
- Not MIME-aware, so the bounce of an 8bit MIME mail will be non-MIME
  compliant, and most likely rejected, thus causing a double bounce
- Original mail is not encapsulated, so any non-text mail gets a
  garbled bounce

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sun, 11 Jan 2009 17:39:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 11 Jan 2009 17:39:05 GMT) Full text and rfc822 format available.

Message #136 received at 510415@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sun, 11 Jan 2009 09:35:38 -0800
Kalle Kivimaa <killer@debian.org> writes:
> Steve Langasek <vorlon@debian.org> writes:

>> Can you expand here on the consequences of ignoring RFC1894?  I'm aware
>> that qmail delivery failure mails look different (and, I might argue,
>> gratuitously so) than those of other mail systems, but does this cause
>> interoperability problems for other Internet users?
>
> RFC1894 ignorance produces at least these problems for interoperability
> in Internet:

Thank you for this list!  It's very useful for the discussion.

> - Translation of the error messages fails

True, but not, I think, a sufficient problem to warrant keeping it out of
the archive.  We have a lot of software that's unfriendly to translations
(unfortuntaley).

> - Mailing list software fails to parse the error message

This is a more serious problem.  Mailman, for example, can't handle qmail
bounce messages very well.  I don't think it, by itself, would be
sufficiently severe to keep it out of the archive, but it's troubling in
combination with other issues.  Were I filing this as a bug, I'd probably
use severity: important.

> - Not MIME-aware, so the bounce of an 8bit MIME mail will be non-MIME
>   compliant, and most likely rejected, thus causing a double bounce

The number of mail servers that can't handle 8-bit messages is thankfully
dropping fast.  I think technical opinions reasonably differ on the merits
of the MIME insistence on 7-bit transport without ESMTP negotiation.  I'm
one of the people who thinks it feels like something out of the 1980s.

> - Original mail is not encapsulated, so any non-text mail gets a
>   garbled bounce

This is definitely a usability issue.  qmail expects MUAs to have
knowledge of its unusual bounce format if they want to understand the
returned message.  I'd probably put this at the same severity as mailing
list interpretation of bounce messages above.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sun, 11 Jan 2009 23:42:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 11 Jan 2009 23:42:04 GMT) Full text and rfc822 format available.

Message #141 received at 510415@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sun, 11 Jan 2009 15:39:01 -0800
Joerg Jaspert <joerg@debian.org> writes:

> One more thing (I dont think its mentioned already) I got pointed at:
> http://www.daemonology.net/papers/bsdcan06.pdf
> Page 9 says:
> · Bug discovered in qmail: If you can send a >2GB message to qmailsmtpd,
>   you can execute arbitrary code via an integer overflow.
>    ­ Response from DJB: "Nobody gives gigabytes of memory to each
>      qmailsmtpd process".
>    ­ When DJB wrote qmail (1995), this was probably correct.

I've always been annoyed by this very common summary of this problem (not
your fault -- I know you're just quoting).  It omits the key point that
DJB was making in defense of qmail.  If you install qmail following its
installation instructions, qmailsmtpd does indeed not get gigabytes of
memory *because the installation imposes a resource limit on the memory it
can consume*.  So indeed, qmail installed as documented is not vulnerable
to this problem regardless of the size of physical memory on the system.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Mon, 12 Jan 2009 08:39:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 12 Jan 2009 08:39:02 GMT) Full text and rfc822 format available.

Message #146 received at 510415@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Mon, 12 Jan 2009 00:37:38 -0800
On Sat, Jan 10, 2009 at 04:35:59PM +0100, Raphael Hertzog 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?

> 2. 

> 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 would draw a distinction here between "investigate the quality in depth"
and "judge the quality".  I don't think the ftp team has an obligation to do
a lot of investigation, and I think the project as a whole is happier if
they don't do this (since it would cause the NEW queue to be more of a
bottleneck).  But they do make a judgement call on the quality of each
package that they let into the archive, based on the available information.

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

Do the definitions of "grave" and "critical" bugs found in the BTS
documentation serve, in your opinion, to identify software that's "crap"?
Would giving the ftp team explicit authority to block packages that
obviously fail this standard resolve the dispute?

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

Personally, I don't agree.  If a package fails the most basic QA criteria,
I think it's reasonable to require the maintainer to address this before
allowing the package into the archive where it will consume central project
resources (especially mirror network space, which is one of the resources
with the highest per-package cost, and does not scale linearly).

OTOH, suppose that a package is rejected from the NEW queue because the
ftp team notices a grave bug, and the maintainer reuploads fixing this grave
bug and the ftp team then notices a second grave bug that was already there.
Rejecting the package a second time will frustrate the maintainer and seems
unnecessary from the standpoint of protecting the quality of the archive,
since the maintainer has already demonstrated a committment to addressing
major issues.  This ties into Sam's comments about encouraging "processes
that enable individuals to make forward progress", which are spot on.

-- 
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@ubuntu.com                                     vorlon@debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Mon, 12 Jan 2009 12:48:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 12 Jan 2009 12:48:02 GMT) Full text and rfc822 format available.

Message #151 received at 510415@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Mon, 12 Jan 2009 13:46:07 +0100
On Mon, 12 Jan 2009, Steve Langasek wrote:
> > 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.
> 
> Do the definitions of "grave" and "critical" bugs found in the BTS
> documentation serve, in your opinion, to identify software that's "crap"?

Yes, but only if they can't be fixed (or if they can but aren't because
upstream doesn't want to and/or the maintainer doesn't have the required
skills).

> Would giving the ftp team explicit authority to block packages that
> obviously fail this standard resolve the dispute?

It's certainly a good step to clarify the situation.

> > 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.
> 
> Personally, I don't agree.  If a package fails the most basic QA criteria,
> I think it's reasonable to require the maintainer to address this before
> allowing the package into the archive where it will consume central project
> resources (especially mirror network space, which is one of the resources
> with the highest per-package cost, and does not scale linearly).
> 
> OTOH, suppose that a package is rejected from the NEW queue because the
> ftp team notices a grave bug, and the maintainer reuploads fixing this grave
> bug and the ftp team then notices a second grave bug that was already there.
> Rejecting the package a second time will frustrate the maintainer and seems
> unnecessary from the standpoint of protecting the quality of the archive,
> since the maintainer has already demonstrated a committment to addressing
> major issues.  This ties into Sam's comments about encouraging "processes
> that enable individuals to make forward progress", which are spot on.

Indeed, I consider this an acceptable compromise but one that is not so
easy to put in place. In particular when multiple people do NEW
processing.

Cheers,
-- 
Raphaël Hertzog

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Mon, 02 Feb 2009 16:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Gerrit Pape <pape@dbnbgs.smarden.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 02 Feb 2009 16:42:03 GMT) Full text and rfc822 format available.

Message #156 received at 510415@bugs.debian.org (full text, mbox):

From: Gerrit Pape <pape@dbnbgs.smarden.org>
To: 510415@bugs.debian.org
Cc: Joerg Jaspert <joerg@debian.org>
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Mon, 2 Feb 2009 16:38:44 +0000
On Tue, Jan 06, 2009 at 12:38:11AM +0000, Ian Jackson wrote:
> Joerg Jaspert writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian"):
> > Criteria that speak against inclusion:
> > - no real upstream

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

There's a team around 'netqmail' which is considered upstream nowadays,
 http://qmail.org/netqmail/

Nevertheless, I do think I have the skills an experience to work with
the source in case upstream isn't responsible.

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

I've heard that before[*], but must confess, this still doesn't change
my mind.  I know that my opinion on some matters of the Internet mail
infrastructure are not in line with, it looks so, what most other people
in Debian think.  But I'm still of that opinion, and judge arguments
speaking against it differently, just as my arguments against the other
opinion are judged differently, or not properly understood.

[*] http://lists.debian.org/debian-devel/2008/12/msg00305.html
    and followups

I'm using qmail on Debian, providing unofficial packages through
http://smarden.org/pape/Debian/ and developing around qmail since ages.
After qmail was released into the public domain, I've been approached by
users, asking me to make the qmail packages available officially through
Debian/main.  That's what motivated me to adapt the existing package so
that they comply with the Debian policy, as the unofficial ones did
not completely.

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

>   * For each such criticism, what your opinion of it is and what
>     if anything you plan to do about it.

That's what I read from this thread, cut down to the minimum, criticisms
that seem to be release critical:

(1) delayed bounces.  By default, qmail first accepts mail injected into
the system on port 25, and, if it cannot be delivered, a separate bounce
message is injected.
(joerg, ian, russ)

(2) Andree's 'Qmail bugs and wishlist' page at
http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html
(joerg, kalle)

(3) How the suggested packages handle the 'newaliases' program
(Steve)

Other points like 'no upstream', 'FHS violation', 'better MTA already
available' don't seem to be issues or judged RC, and may be handled
through normal bug reports I think.

If I forgot additional criticisms, please followup and add to the list.

My opinion on

(1) while not agreeing completely (see beginning of the mail), after all
it's just fine with the RFCs, I'm okay with changing the packages so
that in the default install mail to unknown users received through SMTP
is rejected during the SMTP session, and doesn't cause a separate bounce
message.

(2) Only 'Part I: Bugs' seems to be relevant
 1.1 doesn't apply.  The prospective packages follow 'Life with qmail'
 almost completely.
 1.2 see (1).
 1.3 qmail-qmtpd isn't enabled by default.  If enabled, it's considered
 a protocol to be used between machines that trust each other.
 1.4 doesn't apply.  Resource limits are set appropriately.
 2.1 I'd suggest not to change that, it's a good compromise between
 performance and reliability.
 2.2 qmail's MDA qmail-local doesn't override files on name collisions,
 but stops, and retries later.  If there's really mail loss, some MUA
 misses the required sanity checks.
 2.3 I fail to see the impact.
 3.1 I think it's a minor problem if at all, please see
 http://lists.debian.org/debian-devel/2008/12/msg00238.html
 3.2 I think it's a minor problem if at all, please see
 http://lists.debian.org/debian-devel/2008/12/msg00238.html
 3.3 It's news to be that MIME DSN's are mandatory these days, when has
 this changed (serious question)?  RFC1894, Abstract, starts with 'This
 memo defines a MIME content-type that may be used by a message'...
 3.4 Might be a bug, I didn't look into that deeply, didn't notice any
 impact yet.  pop3 isn't enabled by the prospective packages.

See also http://lists.debian.org/debian-devel/2008/12/msg00238.html

I'd prefer to not address any of these issues in the qmail packages.
The target audience of the packages are people using qmail because they
think it's the best choice for their security requirements.  One way to
achieve this level of security of qmail was that the code proved to be
secure over a very long time, without changing.  As soon as lots of
changes are introduced, the security, or reputation, may suffer.  I'd
like to only introduce patches where really necessary.

(3) I was of the opinion that a dependency chain to a packages that
provides the newliases program is enough to conform with the Debian
policy, and, since Recommends are install by default, recommending the
fastforward package is sufficient, while preserving flexibility.  I now
see that on systems where exim is installed as default MTA, installing
the fastforward package will result in a file conflict.  The packages
should be adapted, so that the qmail-run package provides the newaliases
program.

Regards, Gerrit.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sun, 01 Mar 2009 20:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Gerrit Pape <pape@dbnbgs.smarden.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 01 Mar 2009 20:33:05 GMT) Full text and rfc822 format available.

Message #161 received at 510415@bugs.debian.org (full text, mbox):

From: Gerrit Pape <pape@dbnbgs.smarden.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sun, 1 Mar 2009 20:32:11 +0000
On Tue, Feb 03, 2009 at 08:32:20AM +0000, Gerrit Pape wrote:
> On Tue, Jan 06, 2009 at 12:38:11AM +0000, Ian Jackson wrote:
> >   * For each such criticism, what your opinion of it is and what
> >     if anything you plan to do about it.

> (3) How the suggested packages handle the 'newaliases' program
> (Steve)

> My opinion on

> (3) I was of the opinion that a dependency chain to a packages that
> provides the newliases program is enough to conform with the Debian
> policy, and, since Recommends are install by default, recommending the
> fastforward package is sufficient, while preserving flexibility.  I now
> see that on systems where exim is installed as default MTA, installing
> the fastforward package will result in a file conflict.  The packages
> should be adapted, so that the qmail-run package provides the newaliases
> program.

Actually, with the first set of packages uploaded to ftp-master in April
2008, the qmail-run package included a minimal newaliases program (doing
nothing but output a warning).  The fastforward package, if installed,
diverted and replaced the newaliases program with a full functional
version, giving users the choice.  AFAICS this was compliant with our
policy, but rejected by ftpmasters[*].  I chose to follow ftpmasters'
suggestion back then.

Would reverting this change concerning newaliases be acceptable for you,
and solve the newaliases-issue?

[*] http://smarden.org/pape/Debian/1215531259.4854_332.werc


Is there generally any (maybe invisible) progress on this bug's topic?

Thanks, Gerrit.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Tue, 26 May 2009 16:27:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to peter@madams.com:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 26 May 2009 16:27:02 GMT) Full text and rfc822 format available.

Message #166 received at 510415@bugs.debian.org (full text, mbox):

From: Peter Madams <peter@madams.com>
To: 510415@bugs.debian.org
Cc: pape@dbnbgs.smarden.org
Subject: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Tue, 26 May 2009 09:16:33 -0700
[Message part 1 (text/plain, inline)]
Hi,
Gerrit Page has been trying to add a qmail package, for a long time!
http://smarden.org/pape/Debian/sid.html


What's the problem?


I have been using qmail with Debian for years, it is the only MTA
to offer me the security, performance and flexibility that I need.

I want to add my name to the the many qmail users who request
that you complete the process.

Please add this package and save me time in having to manually
update all my machines - at home and at my business.

Thank you,
-PeterM
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Tue, 26 May 2009 17:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to peter@madams.com:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 26 May 2009 17:27:03 GMT) Full text and rfc822 format available.

Message #171 received at 510415@bugs.debian.org (full text, mbox):

From: Peter Madams <peter@madams.com>
To: 510415@bugs.debian.org
Subject: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Tue, 26 May 2009 10:16:16 -0700
[Message part 1 (text/plain, inline)]
Hi,
Gerrit Page has been trying to add a qmail package, for a long time!
http://smarden.org/pape/Debian/sid.html


What's the problem?


I have been using qmail with Debian for years, it is the only MTA
to offer me the security, performance and flexibility that I need.

I want to add my name to the the many qmail users who request
that you complete the process.

Please add this package and save me time in having to manually
update all my machines - at home and at my business.

Thank you,
-PeterM
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Tue, 26 May 2009 18:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 26 May 2009 18:48:03 GMT) Full text and rfc822 format available.

Message #176 received at 510415@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Peter Madams <peter@madams.com>
Cc: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Tue, 26 May 2009 11:33:09 -0700
Peter Madams <peter@madams.com> writes:

> Gerrit Page has been trying to add a qmail package, for a long time!
> http://smarden.org/pape/Debian/sid.html
>
> What's the problem?

http://bugs.debian.org/510415 documents the problems at some length.  I
don't think everyone agrees about the problems or the best solutions,
but that's at least the answer to your question.

I think the ball is currently in the tech-ctte's court to respond to the
last message from Gerrit.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sat, 25 Jul 2009 18:09:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 25 Jul 2009 18:09:05 GMT) Full text and rfc822 format available.

Message #181 received at 510415@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: debian-ctte@lists.debian.org, 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sat, 25 Jul 2009 20:05:50 +0200
Hi,


trying to summarize the discussion, there are a few technical issues:

a. By far most important is the topic of delayed bounces. Gerit
offered to change the default to not produce them.

b. There are lots of issues why qmail doesn't look too competitive,
like the static user ids, ignorance of rfc 3464, unbundling of
outgoing messages etc. None of them is by itself critical, but they
(together) would prevent me from using qmail.

c. There are some (small) issues like that newaliases is provided by
another package. However, any of these issues has an obvious
resolution path, so they shouldn't be blocking.



So, I can see three different ways to continue. In any case a. and c.
should be fixed if the package is allowed into Debian.

1. Allow qmail to go into Debian (including squeeze).

2. Allow qmail into Debian unstable, but prevent it (at least for now)
from entering testing.

3. Not allow qmail into Debian.

(4. Further discussion)


I would tend to make the decision about stable in 1. and 2. only
temporary and allow the release team to change it as they see fit (as
the question is delegated by ftp-masters and also the "usual policy"
for RC bug does aplpy, I also think this is necessary).

Comments? Opinions?



Cheers,
Andi




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sat, 25 Jul 2009 22:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 25 Jul 2009 22:51:03 GMT) Full text and rfc822 format available.

Message #186 received at 510415@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: debian-ctte@lists.debian.org, 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sat, 25 Jul 2009 15:50:13 -0700
Andreas Barth <aba@not.so.argh.org> writes:

> So, I can see three different ways to continue. In any case a. and c.
> should be fixed if the package is allowed into Debian.
>
> 1. Allow qmail to go into Debian (including squeeze).
>
> 2. Allow qmail into Debian unstable, but prevent it (at least for now)
> from entering testing.
>
> 3. Not allow qmail into Debian.
>
> (4. Further discussion)
>
>
> I would tend to make the decision about stable in 1. and 2. only
> temporary and allow the release team to change it as they see fit (as
> the question is delegated by ftp-masters and also the "usual policy" for
> RC bug does aplpy, I also think this is necessary).

I don't like 2 -- I think that the point of Debian is to allow the normal
process of migration from unstable into testing into stable releases to
happen, and if we're not planning on allowing something to release, it
doesn't make sense to pull it into unstable in the first place.

I'm sympathetic to the idea of not allowing into the archive lots of
duplicate implementations of the same basic function, particularly when
some alternatives seem technically inferior to others.  However, qmail
also isn't just a random MTA that no one has otherwise heard of.  We know
there's a group of Debian users who want to use it and who have been using
the installer packages prior to the change of licensing.  It's also a
rather unusual MTA, which means that people who were already using it for
some reason often won't find it easy to migrate away from it.  It's
definitely not the case that one can just replace qmail with a nontrivial
configuration with Postfix easily.  To me, that argues against viewing it
as interchangeable with other MTAs.

I do think that accept and bounce these days is a show-stopper, but with
that fixed, I have a hard time seeing the other issues as show-stoppers.
I do think that the newaliases integration should be fixed so that Policy
aliases handling works, but I agree that's relatively straightforward to
deal with.  So I'm personally leaning towards the general principle that
if we've got an active maintainer who wants the package in Debian and is
technically capable of maintaining it, we should lean towards accepting
it.

However, I'm still a bit worried that I'm missing some show-stopper
problem.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Fri, 07 Aug 2009 17:18:16 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 07 Aug 2009 17:18:17 GMT) Full text and rfc822 format available.

Message #191 received at 510415@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 7 Aug 2009 09:18:11 -0700
On Sat, 25 Jul 2009, Andreas Barth wrote:
> So, I can see three different ways to continue. In any case a. and c.
> should be fixed if the package is allowed into Debian.
> 
> 1. Allow qmail to go into Debian (including squeeze).
> 
> 2. Allow qmail into Debian unstable, but prevent it (at least for now)
> from entering testing.
> 
> 3. Not allow qmail into Debian.
> 
> (4. Further discussion)

A slightly different possibility:

1. Allow qmail to enter without precondition

2. Allow qmail to enter unstable (or experimental?); an RC bug to be
filed preventing normal transition for a period of at least a month to
allow for additional RC (or non-RC) bugs to be filed. After a month,
the RM or the maintainer can continue to decide that the package is
not acceptable for release at their discretion, as happens for any
package. [If the RM or maintainer don't reaffirm the transition
blocking bug, the ctte will close the transition blocking bug.]

3. Do not allow qmail into Debian

4. Further discussion.

I'm personally leaning towards something along the lines of #2, with a
an immediate RC bug just to allow a slightly longer period for bugs to
be filed and things to get worked out before it enters testing.

If there aren't any objections to #2, I think we should clean up the
language, and put out a sample ballot and call for a vote.
 

Don Armstrong

-- 
Show me your flowcharts and conceal your tables, and I shall continue
to be mystified. Show me your tables, and I won't usually need your
flowcharts; they'll be obvious.
 -- Fredrick P. Brooks Jr., The Mythical Man Month

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Tue, 11 Aug 2009 21:03:02 GMT) Full text and rfc822 format available.

Message #194 received at 510415@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Tue, 11 Aug 2009 14:01:42 -0700
On Fri, 07 Aug 2009, Don Armstrong wrote:
> On Sat, 25 Jul 2009, Andreas Barth wrote:
> > So, I can see three different ways to continue. In any case a. and c.
> > should be fixed if the package is allowed into Debian.
> > 
> > 1. Allow qmail to go into Debian (including squeeze).
> > 
> > 2. Allow qmail into Debian unstable, but prevent it (at least for now)
> > from entering testing.
> > 
> > 3. Not allow qmail into Debian.
> > 
> > (4. Further discussion)
> 
> A slightly different possibility:

[writing this up for a potential vote; if there aren't any changes,
I'll ask to open voting in 48 hours. (If you have a change and you're
busy, let me know to hold.)]

1. Qmail is to be allowed into the archive without special
preconditions. Ftpmaster should perform standard NEW processing for
licensing, copyright, and general packaging issues as normal.

2. Qmail is to be allowed into the archive without special
preconditions, save the RC bug indicated below. Ftpmaster should
perform standard NEW processing for licensing, copyright, and general
packaging issues as normal. with the addition of an RC bug filed
immediately to preventing normal transition for a period of at least a
month after traversing NEW.

During this period, additional RC (or non-RC) bugs should be filed by
interested parties, and updated qmail packages fixing these bugs
should be uploaded as usual. After a month, the RM or the maintainer
can continue to decide that the package is not acceptable for release
at their discretion, as happens for any package. [If the RM or
maintainer don't reaffirm the transition blocking bug, the ctte will
close the transition blocking bug.]

3. Qmail is not to be allowed into Debian.

4. Further discussion.


It is my understanding that we have been asked to make this decision
under §6.1.3, so a simple majority is sufficient.


Don Armstrong

-- 
The smallest quantity of bread that can be sliced and toasted has yet
to be experimentally determined. In the quantum limit we must
necessarily encounter fundamental toast particles which the author
will unflinchingly designate here as "croutons".
 -- Cser, Jim. Nanotechnology and the Physical Limits of Toastability.
    AIR 1:3, June, 1995.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Wed, 12 Aug 2009 05:24:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 12 Aug 2009 05:24:08 GMT) Full text and rfc822 format available.

Message #199 received at 510415@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: debian-ctte@lists.debian.org
Cc: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Wed, 12 Aug 2009 07:23:22 +0200
* Don Armstrong (don@debian.org) [090811 23:04]:
> 1. Qmail is to be allowed into the archive without special
> preconditions. Ftpmaster should perform standard NEW processing for
> licensing, copyright, and general packaging issues as normal.

As of now, qmail should definitly not be allowed into the archive. I
would rather prefer to state the issues that need to be changed and
that we already know as of now as part of the decision.



Cheers,
Andi




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Wed, 12 Aug 2009 06:27:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 12 Aug 2009 06:27:02 GMT) Full text and rfc822 format available.

Message #204 received at 510415@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Tue, 11 Aug 2009 23:22:08 -0700
On Wed, 12 Aug 2009, Andreas Barth wrote:
> * Don Armstrong (don@debian.org) [090811 23:04]:
> > 1. Qmail is to be allowed into the archive without special
> > preconditions. Ftpmaster should perform standard NEW processing for
> > licensing, copyright, and general packaging issues as normal.
> 
> As of now, qmail should definitly not be allowed into the archive. I
> would rather prefer to state the issues that need to be changed and
> that we already know as of now as part of the decision.

Would it be enough for these issues to be filed as RC bugs and the
package be allowed into unstable, or is there a set of issues that
need to be fixed before this happens? [If there is a set, what is it?]

I'm fine with specifically spelling out the issues that we're already
aware of needing to be fixed; I just think it's not fair to the
prospective maintainer to have a moving set of things to fix for
uploading to the archive. [It's perfectly reasonable to have a moving
set of things to fix for propogation to testing, though.]


Don Armstrong

-- 
[On a trip back from collecting grass seeds in tropical bird stomachs
and being thought by the customs agents to be transporting Marijuana.]
"Anyone so square as to tell you they are transporting grass seeds is
bound to be ok"
 -- Peter K. Klopfer _Seeds of Doubt_ Science 134:177 10 April 2009

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Fri, 14 Aug 2009 02:45:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 14 Aug 2009 02:45:02 GMT) Full text and rfc822 format available.

Message #209 received at 510415@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Thu, 13 Aug 2009 19:43:56 -0700
Don Armstrong <don@debian.org> writes:

> Would it be enough for these issues to be filed as RC bugs and the
> package be allowed into unstable, or is there a set of issues that
> need to be fixed before this happens? [If there is a set, what is it?]

> I'm fine with specifically spelling out the issues that we're already
> aware of needing to be fixed; I just think it's not fair to the
> prospective maintainer to have a moving set of things to fix for
> uploading to the archive. [It's perfectly reasonable to have a moving
> set of things to fix for propogation to testing, though.]

I agree with Don on this, for the record.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Tue, 18 Aug 2009 23:09:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 18 Aug 2009 23:09:08 GMT) Full text and rfc822 format available.

Message #214 received at 510415@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Tue, 18 Aug 2009 16:05:51 -0700
On Fri, 14 Aug 2009, Andreas Barth wrote:
> I think it would be good to get rid of at least the "does delayed
> bounces" before upload.

Ok.

> For all the other issues, RC bugs are an option.

Right.

> I also think that even in case we decide to allow qmail in that
> still gives the ftp-team the chance to remove it for having
> unhandled RC bugs for a too long time (that's in case the other
> issues are not fixed).

Right; this would be the standard RoQA/RoM/RoFTPM methods.

So, what about the following:

1. Qmail is to be allowed into the archive without special
preconditions. Ftpmaster should perform standard NEW processing for
licensing, copyright, and general packaging issues as normal.

Qmail is subject to the normal removal process for packages.

2. Qmail is to be allowed into the archive without special
preconditions, save the RC bug indicated below. Ftpmaster should
perform standard NEW processing for licensing, copyright, and general
packaging issues as normal. with the addition of an RC bug filed
immediately to preventing normal transition for a period of at least a
month after traversing NEW.

During this period, additional RC (or non-RC) bugs should be filed by
interested parties, and updated qmail packages fixing these bugs
should be uploaded as usual. After a month, the RM or the maintainer
can continue to decide that the package is not acceptable for release
at their discretion, as happens for any package. [If the RM or
maintainer don't reaffirm the transition blocking bug, the ctte will
close the transition blocking bug.]

Qmail is subject to the normal removal process for packages.

3. Qmail is to be allowed in to the archive after a patch to resolve
the delayed bounces issue, where mail sent to an invalid recipient
which a reasonable MTA is capable of knowing is invalid is accepted
instead of being rejected at RCPT TO time. After upload, the process
outlined in option #2 will take effect.

4. Qmail is not to be allowed into Debian.

5. Further discussion.


Lets see if we can at least do another go around in the next 48 hours,
or begin the process of calling for votes then.


Don Armstrong

-- 
This isn't life in the fast lane, it's life in the oncoming traffic
 -- Terry Pratchett

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Fri, 21 Aug 2009 18:45:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 21 Aug 2009 18:45:12 GMT) Full text and rfc822 format available.

Message #219 received at 510415@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 510415@bugs.debian.org
Subject: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Thu, 20 Aug 2009 21:00:47 -0700
I'm calling for a vote on the following options[1]:

| 1. Qmail is to be allowed into the archive without special
| preconditions. Ftpmaster should perform standard NEW processing for
| licensing, copyright, and general packaging issues as normal.
| 
| Qmail is subject to the normal removal process for packages.
| 
| 2. Qmail is to be allowed into the archive without special
| preconditions, save the RC bug indicated below. Ftpmaster should
| perform standard NEW processing for licensing, copyright, and general
| packaging issues as normal. with the addition of an RC bug filed
| immediately to preventing normal transition for a period of at least a
| month after traversing NEW.
| 
| During this period, additional RC (or non-RC) bugs should be filed by
| interested parties, and updated qmail packages fixing these bugs
| should be uploaded as usual. After a month, the RM or the maintainer
| can continue to decide that the package is not acceptable for release
| at their discretion, as happens for any package. [If the RM or
| maintainer don't reaffirm the transition blocking bug, the ctte will
| close the transition blocking bug.]
| 
| Qmail is subject to the normal removal process for packages.
| 
| 3. Qmail is to be allowed in to the archive after a patch to resolve
| the delayed bounces issue, where mail sent to an invalid recipient
| which a reasonable MTA is capable of knowing is invalid is accepted
| instead of being rejected at RCPT TO time. After upload, the process
| outlined in option #2 will take effect.
| 
| 4. Qmail is not to be allowed into Debian.
| 
| 5. Further discussion.


Don Armstrong

1: With apologies if someone's made suggestions/objections while this
is in transit.
-- 
Quite the contrary; they *love* collateral damage. If they can make
you miserable enough, maybe you'll stop using email entirely. Once
enough people do that, then there'll be no legitimate reason left for
anyone to run an SMTP server, and the spam problem will be solved.
 -- Craig Dickson in <20020909231134.GA18917@linux700.localnet>

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Fri, 21 Aug 2009 19:03:17 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 21 Aug 2009 19:03:17 GMT) Full text and rfc822 format available.

Message #224 received at 510415@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 21 Aug 2009 12:02:16 -0700
[Message part 1 (text/plain, inline)]
Don Armstrong <don@debian.org> writes:

> I'm calling for a vote on the following options[1]:

> | 1. Qmail is to be allowed into the archive without special
> | preconditions. Ftpmaster should perform standard NEW processing for
> | licensing, copyright, and general packaging issues as normal.
> | 
> | Qmail is subject to the normal removal process for packages.
> | 
> | 2. Qmail is to be allowed into the archive without special
> | preconditions, save the RC bug indicated below. Ftpmaster should
> | perform standard NEW processing for licensing, copyright, and general
> | packaging issues as normal. with the addition of an RC bug filed
> | immediately to preventing normal transition for a period of at least a
> | month after traversing NEW.
> | 
> | During this period, additional RC (or non-RC) bugs should be filed by
> | interested parties, and updated qmail packages fixing these bugs
> | should be uploaded as usual. After a month, the RM or the maintainer
> | can continue to decide that the package is not acceptable for release
> | at their discretion, as happens for any package. [If the RM or
> | maintainer don't reaffirm the transition blocking bug, the ctte will
> | close the transition blocking bug.]
> | 
> | Qmail is subject to the normal removal process for packages.
> | 
> | 3. Qmail is to be allowed in to the archive after a patch to resolve
> | the delayed bounces issue, where mail sent to an invalid recipient
> | which a reasonable MTA is capable of knowing is invalid is accepted
> | instead of being rejected at RCPT TO time. After upload, the process
> | outlined in option #2 will take effect.
> | 
> | 4. Qmail is not to be allowed into Debian.
> | 
> | 5. Further discussion.

I vote: 3 2 1 4 5

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Fri, 21 Aug 2009 19:27:07 GMT) Full text and rfc822 format available.

Message #227 received at 510415@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 21 Aug 2009 12:18:02 -0700
[Message part 1 (text/plain, inline)]
On Thu, 20 Aug 2009, Don Armstrong wrote:
> I'm calling for a vote on the following options[1]:
> 
> | 1. Qmail is to be allowed into the archive without special
> | preconditions. Ftpmaster should perform standard NEW processing for
> | licensing, copyright, and general packaging issues as normal.
> | 
> | Qmail is subject to the normal removal process for packages.
> | 
> | 2. Qmail is to be allowed into the archive without special
> | preconditions, save the RC bug indicated below. Ftpmaster should
> | perform standard NEW processing for licensing, copyright, and general
> | packaging issues as normal. with the addition of an RC bug filed
> | immediately to preventing normal transition for a period of at least a
> | month after traversing NEW.
> | 
> | During this period, additional RC (or non-RC) bugs should be filed by
> | interested parties, and updated qmail packages fixing these bugs
> | should be uploaded as usual. After a month, the RM or the maintainer
> | can continue to decide that the package is not acceptable for release
> | at their discretion, as happens for any package. [If the RM or
> | maintainer don't reaffirm the transition blocking bug, the ctte will
> | close the transition blocking bug.]
> | 
> | Qmail is subject to the normal removal process for packages.
> | 
> | 3. Qmail is to be allowed in to the archive after a patch to resolve
> | the delayed bounces issue, where mail sent to an invalid recipient
> | which a reasonable MTA is capable of knowing is invalid is accepted
> | instead of being rejected at RCPT TO time. After upload, the process
> | outlined in option #2 will take effect.
> | 
> | 4. Qmail is not to be allowed into Debian.
> | 
> | 5. Further discussion.

I vote 3 2 1 4 5.


Don Armstrong

-- 
If you wish to strive for peace of soul, then believe; if you wish to
be a devotee of truth, then inquire.
 -- Friedrich Nietzsche

http://www.donarmstrong.com              http://rzlab.ucr.edu
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sat, 22 Aug 2009 03:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 22 Aug 2009 03:54:03 GMT) Full text and rfc822 format available.

Message #232 received at 510415@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 21 Aug 2009 22:29:37 -0500
[Message part 1 (text/plain, inline)]
On Thu, Aug 20 2009, Don Armstrong wrote:

> I'm calling for a vote on the following options[1]:
>
> | 1. Qmail is to be allowed into the archive without special
> | preconditions. Ftpmaster should perform standard NEW processing for
> | licensing, copyright, and general packaging issues as normal.
> | 
> | Qmail is subject to the normal removal process for packages.
> | 
> | 2. Qmail is to be allowed into the archive without special
> | preconditions, save the RC bug indicated below. Ftpmaster should
> | perform standard NEW processing for licensing, copyright, and general
> | packaging issues as normal. with the addition of an RC bug filed
> | immediately to preventing normal transition for a period of at least a
> | month after traversing NEW.
> | 
> | During this period, additional RC (or non-RC) bugs should be filed by
> | interested parties, and updated qmail packages fixing these bugs
> | should be uploaded as usual. After a month, the RM or the maintainer
> | can continue to decide that the package is not acceptable for release
> | at their discretion, as happens for any package. [If the RM or
> | maintainer don't reaffirm the transition blocking bug, the ctte will
> | close the transition blocking bug.]
> | 
> | Qmail is subject to the normal removal process for packages.
> | 
> | 3. Qmail is to be allowed in to the archive after a patch to resolve
> | the delayed bounces issue, where mail sent to an invalid recipient
> | which a reasonable MTA is capable of knowing is invalid is accepted
> | instead of being rejected at RCPT TO time. After upload, the process
> | outlined in option #2 will take effect.
> | 
> | 4. Qmail is not to be allowed into Debian.
> | 
> | 5. Further discussion.


        I vote:
 3 1 2 4 5

        manoj
-- 
"The one charm of marriage is that it makes a life of deception a
neccessity." Oscar Wilde
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sun, 23 Aug 2009 09:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 23 Aug 2009 09:33:03 GMT) Full text and rfc822 format available.

Message #237 received at 510415@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: debian-ctte@lists.debian.org
Cc: 510415@bugs.debian.org
Subject: Re: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sun, 23 Aug 2009 02:22:32 -0700
[Message part 1 (text/plain, inline)]
On Thu, Aug 20, 2009 at 09:00:47PM -0700, Don Armstrong wrote:
> I'm calling for a vote on the following options[1]:

> | 1. Qmail is to be allowed into the archive without special
> | preconditions. Ftpmaster should perform standard NEW processing for
> | licensing, copyright, and general packaging issues as normal.
> | 
> | Qmail is subject to the normal removal process for packages.
> | 
> | 2. Qmail is to be allowed into the archive without special
> | preconditions, save the RC bug indicated below. Ftpmaster should
> | perform standard NEW processing for licensing, copyright, and general
> | packaging issues as normal. with the addition of an RC bug filed
> | immediately to preventing normal transition for a period of at least a
> | month after traversing NEW.
> | 
> | During this period, additional RC (or non-RC) bugs should be filed by
> | interested parties, and updated qmail packages fixing these bugs
> | should be uploaded as usual. After a month, the RM or the maintainer
> | can continue to decide that the package is not acceptable for release
> | at their discretion, as happens for any package. [If the RM or
> | maintainer don't reaffirm the transition blocking bug, the ctte will
> | close the transition blocking bug.]
> | 
> | Qmail is subject to the normal removal process for packages.
> | 
> | 3. Qmail is to be allowed in to the archive after a patch to resolve
> | the delayed bounces issue, where mail sent to an invalid recipient
> | which a reasonable MTA is capable of knowing is invalid is accepted
> | instead of being rejected at RCPT TO time. After upload, the process
> | outlined in option #2 will take effect.
> | 
> | 4. Qmail is not to be allowed into Debian.
> | 
> | 5. Further discussion.

I vote: 5 3 4 2 1

I am concerned that this has gone to a vote without any actual answers to
the questions posed in <20090812062208.GF9480@rzlab.ucr.edu>.  My
understanding following the TC BoF at DebConf9 was that we would be
reviewing some list of known qmail problems that someone had mentioned
there, and that we would additionally consider some bug Ian had direct
experience with that was believed to not be on that list.  This doesn't
appear to have happened; instead we're voting on a set of options that lets
us treat one particular RC bug as a blocker for archive inclusion, without
really looking around and doing the sort of due diligence that I would
expect the ftp team themselves to have done before accepting such a
historically problematic package.

I realize that this bug has been sitting unresolved for an inappropriately
long time, but it seems to me that with this vote we're trying to rush it
through to a conclusion, and in the process making a poorer decision than
the team who delegated this to us would have made.

Certainly, I see a number of issues on
<http://home.pages.de/~mandree/qmail-bugs.html> that I would not like to see
in any package in the archive, not just the delayed-reject bug, and I would
like to know from Gerrit which of the described bugs are addressed in the
qmail package before giving it a green light for archive inclusion.

I do agree that it's not fair to have a moving set of things to fix for
uploading to the archive, but I think that just means we have an obligation
to examine the package carefully and enumerate that set of critical bugs,
not that we should call it good with the one critical bug that's currently
been identified to this list.

-- 
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@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sun, 23 Aug 2009 09:45:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 23 Aug 2009 09:45:04 GMT) Full text and rfc822 format available.

Message #242 received at 510415@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: debian-ctte@lists.debian.org
Cc: Andreas Barth <aba@not.so.argh.org>, 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sun, 23 Aug 2009 02:32:36 -0700
[Message part 1 (text/plain, inline)]
On Sat, Jul 25, 2009 at 08:05:50PM +0200, Andreas Barth wrote:
> b. There are lots of issues why qmail doesn't look too competitive,
> like the static user ids,

I don't see any other mention of static user ids in this discussion.  Can
you explain what the problem is there?  Are these static IDs that have been
allocated in accordance with Debian Policy?

> ignorance of rfc 3464

This is one that I would like to see more discussion about; I've definitely
found qmail's non-standard DSNs irksome, looking like conversational emails
as they do.

>, unbundling of outgoing messages etc.

This is a good reason to not use qmail, but unlike the delayed bounce
problem I don't think it's critical.

> c. There are some (small) issues like that newaliases is provided by
> another package. However, any of these issues has an obvious
> resolution path, so they shouldn't be blocking.

What other issues besides the newaliases issue do you include here?

I think the newaliases policy violation should have also been listed as a
blocker for NEW inclusion, on the ballot.

-- 
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@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sun, 23 Aug 2009 11:18:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 23 Aug 2009 11:18:06 GMT) Full text and rfc822 format available.

Message #247 received at 510415@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: debian-ctte@lists.debian.org, 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sun, 23 Aug 2009 12:34:29 +0200
* Steve Langasek (vorlon@debian.org) [090823 11:32]:
> On Sat, Jul 25, 2009 at 08:05:50PM +0200, Andreas Barth wrote:
> > b. There are lots of issues why qmail doesn't look too competitive,
> > like the static user ids,
> 
> I don't see any other mention of static user ids in this discussion.  Can
> you explain what the problem is there?  Are these static IDs that have been
> allocated in accordance with Debian Policy?

They are. "Not too competive" isn't a translation of "we need to
disallow the upload", but if I need to choose a MTA that would be a
reason for me to take a closer look at competiting products. I think
this is similar to

> >, unbundling of outgoing messages etc.
> 
> This is a good reason to not use qmail, but unlike the delayed bounce
> problem I don't think it's critical.

for that.



> > c. There are some (small) issues like that newaliases is provided by
> > another package. However, any of these issues has an obvious
> > resolution path, so they shouldn't be blocking.
> 
> What other issues besides the newaliases issue do you include here?
> 
> I think the newaliases policy violation should have also been listed as a
> blocker for NEW inclusion, on the ballot.

I'm ok with that. Currently, nothing is on top of my mind (perhaps
anymore). At least I cannot remember anything where I said "this is
totally bad, and I haven't read a patch for it".


Cheers,
Andi




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sun, 23 Aug 2009 13:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <antti-juhani@kaijanaho.fi>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 23 Aug 2009 13:03:04 GMT) Full text and rfc822 format available.

Message #252 received at 510415@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <antti-juhani@kaijanaho.fi>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sun, 23 Aug 2009 15:46:04 +0300
[Message part 1 (text/plain, inline)]
On Sun, Aug 23, 2009 at 02:32:36AM -0700, Steve Langasek wrote:
> On Sat, Jul 25, 2009 at 08:05:50PM +0200, Andreas Barth wrote:
> > ignorance of rfc 3464
> 
> This is one that I would like to see more discussion about; I've definitely
> found qmail's non-standard DSNs irksome, looking like conversational emails
> as they do.

Not ignorance, but deliberate avoidance.  I've been reading old IETF archives,
and DJB seemed to be quite the troublemaker in Drums.  I get the impression he
thinks the draft standard DSNs are badly engineered.  Many of the other
problems mentioned in the bug logs are similarly about DJB being contrarian.

Not that it matters much for the rest of us.

Personally, I don't see DSN format as a big deal.  It's the most useful in
detecting mailing list bounces, but there are reliable techniques that don't
require parsing bounces, for that.

-- 
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sun, 23 Aug 2009 19:00:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 23 Aug 2009 19:00:14 GMT) Full text and rfc822 format available.

Message #257 received at 510415@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sun, 23 Aug 2009 11:45:18 -0700
On Sun, 23 Aug 2009, Steve Langasek wrote:
> I am concerned that this has gone to a vote without any actual
> answers to the questions posed in
> <20090812062208.GF9480@rzlab.ucr.edu>.

I interpreted Andi's response as one answer, and the lack of any
additional messages as an indication that there wasn't any additions
to the set of bugs which needed to be fixed before allowing an upload
(though the set of bugs to allow it to transition to testing was
larger)... which apparently wasn't the case.

> I do agree that it's not fair to have a moving set of things to fix
> for uploading to the archive, but I think that just means we have an
> obligation to examine the package carefully and enumerate that set
> of critical bugs, not that we should call it good with the one
> critical bug that's currently been identified to this list.

I'm of the personal opinion that having the package in unstable and
enumerating the set of bugs using the BTS is (in general) the best way
to do just this, though the delayed bounce issue is serious enough to
delay the package. There are certainly serious bugs, but in my
opinion, they're not bugs that are severe enough to stop an upload of
qmail to unstable (or in my original thinking, to experimental.)

It would have been nice for these issues to have been raised at some
point in the week which elapsed between me trying to advance the issue
and calling for votes or at least the two days between me sending a
ballot option and calling for votes so they could be properly
addressed. [As a process issue, is there some better way[1] to let
people know that someone is starting to get close to calling for
votes? Should we Cc: CTTE members directly or ping on IRC?]


Don Armstrong

1: I had just assumed that sending a mail to the bug was enough, but
it's certainly an option to do something more, so long as everyone
knows what that is.
-- 
Do not handicap your children by making their lives easy.
 -- Robert Heinlein _Time Enough For Love_ p251

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sun, 23 Aug 2009 20:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 23 Aug 2009 20:18:03 GMT) Full text and rfc822 format available.

Message #262 received at 510415@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: 510415@bugs.debian.org, Gerrit Pape <pape@dbnbgs.smarden.org>
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sun, 23 Aug 2009 13:07:59 -0700
[Message part 1 (text/plain, inline)]
On Sun, Aug 23, 2009 at 02:22:32AM -0700, Steve Langasek wrote:
> Certainly, I see a number of issues on
> <http://home.pages.de/~mandree/qmail-bugs.html> that I would not like to see
> in any package in the archive, not just the delayed-reject bug, and I would
> like to know from Gerrit which of the described bugs are addressed in the
> qmail package before giving it a green light for archive inclusion.

Hmm, doh; apparently this was already addressed in one of the other mails
in this thread that have been waiting for my attention for the past 6
months.

On Tue, Feb 03, 2009 at 08:32:20AM +0000, Gerrit Pape wrote:
>  2.1 I'd suggest not to change that, it's a good compromise between
>  performance and reliability.

  2.1. Bounce message contents are not crash-proof.

  Qmail does not value the contents of a bounce message. Dan documents this
  in a subordinate clause of his qmail reliability FAQ. That means: if your
  qmail is bouncing mail and at the same time, your system crashes, the
  bounce mail contents may be corrupt or incomplete.

This sounds like data loss, which is normally considered a grave bug per
<http://www.debian.org/Bugs/Developer>.  Do people disagree that this is a
grave bug?  If you think it's a grave bug, do you think it should be a
blocker for archive inclusion?

>  2.2 qmail's MDA qmail-local doesn't override files on name collisions,
>  but stops, and retries later.  If there's really mail loss, some MUA
>  misses the required sanity checks.

This is one that I think should have been a blocker if it were present; glad
to hear it's addressed.

>  2.3 I fail to see the impact.

Sounds like it would cause bugs in mail routing by not knowing whether an
address is local.  Not something I think is a blocker.

There's also this one:

  4.12. qmail's sendmail -f is not compatible with sendmail.

  qmail's sendmail wrapper does not implement -f properly, in that it does
  not set the default From: address for messages lacking one, but only
  setting the envelope. This differs from original sendmail behavior and
  breaks some applications.

This behavior contradicts the LSB; from
<http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/baselib-sendmail-1.html>:

  -f name	 	

    explicitly set the envelope sender address for incoming mail. If there
    is no From: header, the address specified in the From: header will also
    be set.

    If the user running sendmail is not sufficiently trusted, then the
    actual sender shall be indicated in the message.

This is not a blocker for the package's inclusion in the archive, but it
must then declare that it Conflicts: lsb-core so that any LSB packages users
wish to install don't silently get an incompatible sendmail implementation. 
(The nullmailer package already in the archive does the same thing; except
that it conflicts with 'lsb', when it should conflict instead with the core
lsb package since sendmail's behavior is part of the core specification.)

Thanks,
-- 
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@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Wed, 26 Aug 2009 22:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 26 Aug 2009 22:30:03 GMT) Full text and rfc822 format available.

Message #267 received at 510415@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Wed, 26 Aug 2009 15:21:27 -0700
[Message part 1 (text/plain, inline)]
On Sun, Aug 23, 2009 at 11:45:18AM -0700, Don Armstrong wrote:
> On Sun, 23 Aug 2009, Steve Langasek wrote:
> > I am concerned that this has gone to a vote without any actual
> > answers to the questions posed in
> > <20090812062208.GF9480@rzlab.ucr.edu>.

> I interpreted Andi's response as one answer, and the lack of any
> additional messages as an indication that there wasn't any additions
> to the set of bugs which needed to be fixed before allowing an upload
> (though the set of bugs to allow it to transition to testing was
> larger)... which apparently wasn't the case.

Well, given the outcome of the DebConf TC BoF, where Ian said he would
follow up regarding the other bug he's encountered which didn't make the
referenced list of qmail bugs, I expected that we would wait for that
information to come in before moving to a vote.

> > I do agree that it's not fair to have a moving set of things to fix
> > for uploading to the archive, but I think that just means we have an
> > obligation to examine the package carefully and enumerate that set
> > of critical bugs, not that we should call it good with the one
> > critical bug that's currently been identified to this list.

> I'm of the personal opinion that having the package in unstable and
> enumerating the set of bugs using the BTS is (in general) the best way
> to do just this, though the delayed bounce issue is serious enough to
> delay the package. There are certainly serious bugs, but in my
> opinion, they're not bugs that are severe enough to stop an upload of
> qmail to unstable (or in my original thinking, to experimental.)

I think that in general, any known bug of RC-severity should be sufficient
grounds to keep a package from being accepted into the archive; tempered by
concern that we not frustrate maintainers by moving the bar (i.e., if the
maintainer has already had to reupload once to fix an RC bug, don't reject
the package from NEW again because of other RC bugs that were overlooked in
the first reject).

So yes, if we're taking a decision delegated to us by the ftp team, I expect
a certain measure of due diligence in identifying the critical bugs in the
package.

> It would have been nice for these issues to have been raised at some
> point in the week which elapsed between me trying to advance the issue
> and calling for votes or at least the two days between me sending a
> ballot option and calling for votes so they could be properly
> addressed.

I thought a clear consensus had emerged from the BoF regarding the steps to
be taken to move this bug forward, so I was unprepared for a change in
status that required timely mail processing on my part.

At any rate, having done my own review now of the data I'm mostly satisfied
with moving this forward.  I would still like to see Ian's input before I'm
willing to change my own vote to move 'further discussion' down the list,
though.

> [As a process issue, is there some better way[1] to let
> people know that someone is starting to get close to calling for
> votes? Should we Cc: CTTE members directly or ping on IRC?]

In my case, a subject line change marking out the fact that there's a draft
up for consideration would go a long way to help me.  Perhaps the "RFR"
(request for review) ad "LCFC" (last call for comments) conventions in use
by several of the Debian l10n teams would be suitable?  But in general, any
subject line change drawing attention to the fact that there's a draft would
do the trick, so that it doesn't get lost amid an arbitrarily-sized set of
other unprocessed mails on the thread.

Thanks,
-- 
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@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Thu, 27 Aug 2009 04:24:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 27 Aug 2009 04:24:11 GMT) Full text and rfc822 format available.

Message #272 received at 510415@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Wed, 26 Aug 2009 21:18:03 -0700
Steve Langasek <vorlon@debian.org> writes:

> This says that:

>    The third component of the multipart/report consists of the original
>    message or some portion thereof.  When the value of the RET parameter
>    is FULL, the full message SHOULD be returned for any DSN which
>    conveys notification of delivery failure.  (However, if the length of
>    the message is greater than some implementation-specified length, the
>    MTA MAY return only the headers even if the RET parameter specified
>    FULL.)  If a DSN contains no notifications of delivery failure, the
>    MTA SHOULD return only the headers.

Well, that's a specification for multipart/report, which qmail doesn't
attempt to comply with.  (Neither do many other MTAs, although more do now
than used to.)

At a basic SMTP protocol level, a lot of mail servers no longer return
bounces at *all*, or at least throttle them heavily, because of the abuse
problems.  They're increasingly useless.

> From <http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html> and
> <http://cr.yp.to/qmail/faq/reliability.html>, it's not at all clear to
> me that qmail handles the headers of a bounced message reliably.  All it
> says is that "bounce message contents" are not crashproof - and the
> contents of a bounce message include, among other things, the headers of
> the original message.

It's been a long time since I ran qmail, but as I recall, and according to
the specification, the bounce includes the entire original message.  The
reliability note is just djb doing the full disclosure thing that he
sometimes does.  The point is that qmail can, in some circumstances, lose
part of the bounce message if the mail system crashes at exactly the wrong
point.  Seems like a rather minor problem to me.

The qmail bounce protocol is documented at:

    http://cr.yp.to/proto/qsbmf.txt

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Thu, 27 Aug 2009 17:27:22 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 27 Aug 2009 17:27:23 GMT) Full text and rfc822 format available.

Message #277 received at 510415@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Thu, 27 Aug 2009 10:10:45 -0700
Steve Langasek <vorlon@debian.org> writes:
> On Wed, Aug 26, 2009 at 09:18:03PM -0700, Russ Allbery wrote:

>> Well, that's a specification for multipart/report, which qmail doesn't
>> attempt to comply with.  (Neither do many other MTAs, although more do
>> now than used to.)

>> At a basic SMTP protocol level, a lot of mail servers no longer return
>> bounces at *all*, or at least throttle them heavily, because of the
>> abuse problems.  They're increasingly useless.

> The backscatter problem certainly gives a compelling reason to try to
> reject at SMTP and avoid the need to bounce, but once a message of mine
> has been accepted by a remote server, if it fails to be delivered I do
> expect a notification.  Servers that refuse to do this are in violation
> of the protocol, and undermine a core feature of SMTP (reliability).

The inbound mail servers at stanford.edu intentionally accept and silently
drop messages that we detect as being viruses or very high-probability
spam.  If we generate a bounce or allow the remote server to generate a
bounce, 99 times out of 100 that mail will end up going to some innocent
third party and may further spread malicious content.  We've tried various
different approaches for this over the years, and we're firmly convinced
that this is the right decision for many different reasons.

I'm afraid the days when reliability was a core SMTP feature are long,
long past, for both this and many other reasons.

>> It's been a long time since I ran qmail, but as I recall, and according
>> to the specification, the bounce includes the entire original message.
>> The reliability note is just djb doing the full disclosure thing that
>> he sometimes does.  The point is that qmail can, in some circumstances,
>> lose part of the bounce message if the mail system crashes at exactly
>> the wrong point.  Seems like a rather minor problem to me.

> If it loses enough of the bounce message then the DSN is potentially
> rendered useless.  I think that's a "data loss" bug, just as I think a
> package sending your existing files off into la-la land on an OOD
> condition is a data loss bug.

I understand where you're coming from, and I recognize that you say bug
rather than RC bug.  I don't object to calling it a bug, but were I the
qmail maintainer, I'd make it severity: normal at most, and more likely
minor.

In terms of practical impact on our users, there just aren't enough people
or enough data possibly affected here.  I'm certain the archive is full of
programs that, if you kill them at exactly the wrong time, will lose more
significant data more frequently than this edge case.  One can start with
any program that doesn't auto-save data files.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Thu, 27 Aug 2009 18:27:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Barth <aba@not.so.argh.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 27 Aug 2009 18:27:04 GMT) Full text and rfc822 format available.

Message #282 received at 510415@bugs.debian.org (full text, mbox):

From: Andreas Barth <aba@not.so.argh.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Thu, 27 Aug 2009 20:24:41 +0200
* Don Armstrong (don@debian.org) [090821 20:46]:
> 
> I'm calling for a vote on the following options[1]:
> | 1. Qmail is to be allowed into the archive without special
> | preconditions. Ftpmaster should perform standard NEW processing for
> | licensing, copyright, and general packaging issues as normal.
> | 
> | Qmail is subject to the normal removal process for packages.
> | 
> | 2. Qmail is to be allowed into the archive without special
> | preconditions, save the RC bug indicated below. Ftpmaster should
> | perform standard NEW processing for licensing, copyright, and general
> | packaging issues as normal. with the addition of an RC bug filed
> | immediately to preventing normal transition for a period of at least a
> | month after traversing NEW.
> | 
> | During this period, additional RC (or non-RC) bugs should be filed by
> | interested parties, and updated qmail packages fixing these bugs
> | should be uploaded as usual. After a month, the RM or the maintainer
> | can continue to decide that the package is not acceptable for release
> | at their discretion, as happens for any package. [If the RM or
> | maintainer don't reaffirm the transition blocking bug, the ctte will
> | close the transition blocking bug.]
> | 
> | Qmail is subject to the normal removal process for packages.
> | 
> | 3. Qmail is to be allowed in to the archive after a patch to resolve
> | the delayed bounces issue, where mail sent to an invalid recipient
> | which a reasonable MTA is capable of knowing is invalid is accepted
> | instead of being rejected at RCPT TO time. After upload, the process
> | outlined in option #2 will take effect.
> | 
> | 4. Qmail is not to be allowed into Debian.
> | 
> | 5. Further discussion.


34215


Cheers,
Andi




Reply sent to Don Armstrong <don@debian.org>:
You have taken responsibility. (Thu, 27 Aug 2009 21:48:14 GMT) Full text and rfc822 format available.

Notification sent to Joerg Jaspert <joerg@debian.org>:
Bug acknowledged by developer. (Thu, 27 Aug 2009 21:48:14 GMT) Full text and rfc822 format available.

Message #287 received at 510415-done@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: 510415-done@bugs.debian.org
Subject: Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Thu, 27 Aug 2009 14:34:16 -0700
On Thu, 27 Aug 2009, Andreas Barth wrote:
> 34215

With 4 people ranking 3 first, and Steve ranking it second, I believe
the outcome is no longer in doubt, and so the CTTE has resolved that

3. Qmail is to be allowed in to the archive after a patch to resolve
the delayed bounces issue, where mail sent to an invalid recipient
which a reasonable MTA is capable of knowing is invalid is accepted
instead of being rejected at RCPT TO time. After upload, the process
outlined in option #2 will take effect.

[From option #2]

Ftpmaster should perform standard NEW processing for licensing,
copyright, and general packaging issues as normal. with the addition
of an RC bug filed immediately to preventing normal transition for a
period of at least a month after traversing NEW.

During this period, additional RC (or non-RC) bugs should be filed by
interested parties, and updated qmail packages fixing these bugs
should be uploaded as usual. After a month, the RM or the maintainer
can continue to decide that the package is not acceptable for release
at their discretion, as happens for any package. [If the RM or
maintainer don't reaffirm the transition blocking bug, the ctte will
close the transition blocking bug.]

Qmail is subject to the normal removal process for packages.

=====

Assuming I haven't made some mistake, I'm closing this bug. I'll
update the webwml pages and notify the appropriate parties.



Don Armstrong

-- 
The state must declare the child to be the most precious treasure of
the people. As long as the government is perceived as working for the
benefit of the children, the people will happily endure almost any
curtailment of liberty and almost any deprivation.
 -- Adolf Hitler _Mein Kampf_ p403

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Fri, 28 Aug 2009 20:00:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bdale Garbee <bdale@gag.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 28 Aug 2009 20:00:04 GMT) Full text and rfc822 format available.

Message #292 received at 510415@bugs.debian.org (full text, mbox):

From: Bdale Garbee <bdale@gag.com>
To: Don Armstrong <don@debian.org>, 510415@bugs.debian.org
Subject: Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 28 Aug 2009 13:55:54 -0600
[Message part 1 (text/plain, inline)]
On Thu, 2009-08-20 at 21:00 -0700, Don Armstrong wrote:
> I'm calling for a vote on the following options[1]:
> 
> | 1. Qmail is to be allowed into the archive without special
> | preconditions. Ftpmaster should perform standard NEW processing for
> | licensing, copyright, and general packaging issues as normal.
> | 
> | Qmail is subject to the normal removal process for packages.
> | 
> | 2. Qmail is to be allowed into the archive without special
> | preconditions, save the RC bug indicated below. Ftpmaster should
> | perform standard NEW processing for licensing, copyright, and general
> | packaging issues as normal. with the addition of an RC bug filed
> | immediately to preventing normal transition for a period of at least a
> | month after traversing NEW.
> | 
> | During this period, additional RC (or non-RC) bugs should be filed by
> | interested parties, and updated qmail packages fixing these bugs
> | should be uploaded as usual. After a month, the RM or the maintainer
> | can continue to decide that the package is not acceptable for release
> | at their discretion, as happens for any package. [If the RM or
> | maintainer don't reaffirm the transition blocking bug, the ctte will
> | close the transition blocking bug.]
> | 
> | Qmail is subject to the normal removal process for packages.
> | 
> | 3. Qmail is to be allowed in to the archive after a patch to resolve
> | the delayed bounces issue, where mail sent to an invalid recipient
> | which a reasonable MTA is capable of knowing is invalid is accepted
> | instead of being rejected at RCPT TO time. After upload, the process
> | outlined in option #2 will take effect.
> | 
> | 4. Qmail is not to be allowed into Debian.
> | 
> | 5. Further discussion.

12354

Bdale

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sat, 29 Aug 2009 09:57:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 29 Aug 2009 09:57:06 GMT) Full text and rfc822 format available.

Message #297 received at 510415@bugs.debian.org (full text, mbox):

From: Kurt Roeckx <kurt@roeckx.be>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sat, 29 Aug 2009 11:46:05 +0200
On Thu, Aug 20, 2009 at 09:00:47PM -0700, Don Armstrong wrote:
> 
> I'm calling for a vote on the following options[1]:
> 
> | 1. Qmail is to be allowed into the archive without special
> | preconditions. Ftpmaster should perform standard NEW processing for
> | licensing, copyright, and general packaging issues as normal.
> | 
> | Qmail is subject to the normal removal process for packages.
> | 
> | 2. Qmail is to be allowed into the archive without special
> | preconditions, save the RC bug indicated below. Ftpmaster should
> | perform standard NEW processing for licensing, copyright, and general
> | packaging issues as normal. with the addition of an RC bug filed
> | immediately to preventing normal transition for a period of at least a
> | month after traversing NEW.
> | 
> | During this period, additional RC (or non-RC) bugs should be filed by
> | interested parties, and updated qmail packages fixing these bugs
> | should be uploaded as usual. After a month, the RM or the maintainer
> | can continue to decide that the package is not acceptable for release
> | at their discretion, as happens for any package. [If the RM or
> | maintainer don't reaffirm the transition blocking bug, the ctte will
> | close the transition blocking bug.]
> | 
> | Qmail is subject to the normal removal process for packages.
> | 
> | 3. Qmail is to be allowed in to the archive after a patch to resolve
> | the delayed bounces issue, where mail sent to an invalid recipient
> | which a reasonable MTA is capable of knowing is invalid is accepted
> | instead of being rejected at RCPT TO time. After upload, the process
> | outlined in option #2 will take effect.
> | 
> | 4. Qmail is not to be allowed into Debian.
> | 
> | 5. Further discussion.

We have 6 of the 7 votes now:
32145 rra
32145 don
31245 srivasta
53421 vorlon
34215 aba
12354 bdale

Note that the constitution has a 1 week voting period for this.
Bdale's mail is about 1 week and 1 day after don's CfV, but
couting it or not doesn't seem to make any difference.

This seems to fall under constitution 6.1.3, and so
has a normal 1:1 majority requirement.

There is a quorum of 2, all option reach quorum.

All option also reach the 1:1 majority requirement.

I think it's clear that option 3 wins.


Kurt





Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sat, 29 Aug 2009 10:21:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Aníbal Monsalve Salazar <anibal@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sat, 29 Aug 2009 10:21:04 GMT) Full text and rfc822 format available.

Message #302 received at 510415@bugs.debian.org (full text, mbox):

From: Aníbal Monsalve Salazar <anibal@debian.org>
To: Kurt Roeckx <kurt@roeckx.be>, 510415@bugs.debian.org
Subject: Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Sat, 29 Aug 2009 20:17:32 +1000
On Sat, Aug 29, 2009 at 11:46:05AM +0200, Kurt Roeckx wrote:
>[...] 
>I think it's clear that option 3 wins.

Your message wasn't signed.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Thu, 17 Sep 2009 09:42:28 GMT) Full text and rfc822 format available.

Acknowledgement sent to Gerrit Pape <pape@dbnbgs.smarden.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 17 Sep 2009 09:42:28 GMT) Full text and rfc822 format available.

Message #307 received at 510415@bugs.debian.org (full text, mbox):

From: Gerrit Pape <pape@dbnbgs.smarden.org>
To: debian-ctte@lists.debian.org, 510415@bugs.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Thu, 17 Sep 2009 09:33:16 +0000
On Sun, Mar 01, 2009 at 08:32:11PM +0000, Gerrit Pape wrote:
> On Tue, Feb 03, 2009 at 08:32:20AM +0000, Gerrit Pape wrote:
> > (3) I was of the opinion that a dependency chain to a packages that
> > provides the newliases program is enough to conform with the Debian
> > policy, and, since Recommends are install by default, recommending the
> > fastforward package is sufficient, while preserving flexibility.  I now
> > see that on systems where exim is installed as default MTA, installing
> > the fastforward package will result in a file conflict.  The packages
> > should be adapted, so that the qmail-run package provides the newaliases
> > program.
> 
> Actually, with the first set of packages uploaded to ftp-master in April
> 2008, the qmail-run package included a minimal newaliases program (doing
> nothing but output a warning).  The fastforward package, if installed,
> diverted and replaced the newaliases program with a full functional
> version, giving users the choice.  AFAICS this was compliant with our
> policy, but rejected by ftpmasters[*].  I chose to follow ftpmasters'
> suggestion back then.
> 
> Would reverting this change concerning newaliases be acceptable for you,
> and solve the newaliases-issue?
> 
> [*] http://smarden.org/pape/Debian/1215531259.4854_332.werc

Hi, I'm not sure I'm reading policy correctly.  Is it okay to provide
such a newaliases program

 #!/bin/sh
 cat >&2 <<EOT
 
 qmail on Debian by default doesn't support the /etc/aliases database,
 but handles mail aliases differently, please see
  http://lifewithqmail.org/lwq.html#aliases
 
 EOT
 exit 1

which will be diverted and replaced by a fully functional version if the
fastforward package is installed?  This way users would be able to
choose which alias mechanism to use easily.

Thanks, Gerrit.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Thu, 17 Sep 2009 21:27:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joerg Jaspert <joerg@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Thu, 17 Sep 2009 21:27:03 GMT) Full text and rfc822 format available.

Message #312 received at 510415@bugs.debian.org (full text, mbox):

From: Joerg Jaspert <joerg@debian.org>
To: Gerrit Pape <pape@dbnbgs.smarden.org>
Cc: 510415@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Thu, 17 Sep 2009 23:20:02 +0200
On 11876 March 1977, Gerrit Pape wrote:

> Hi, I'm not sure I'm reading policy correctly.  Is it okay to provide
> such a newaliases program
>  #!/bin/sh
>  cat >&2 <<EOT
>  qmail on Debian by default doesn't support the /etc/aliases database,
>  but handles mail aliases differently, please see
>   http://lifewithqmail.org/lwq.html#aliases
>  EOT
>  exit 1

> which will be diverted and replaced by a fully functional version if the
> fastforward package is installed?  This way users would be able to
> choose which alias mechanism to use easily.

It is only ok if the smtpd does use the information from /etc/aliases
without newaliases doing anything. Nothing allows you to ignore this
file. So no, with the above output it is not ok.

The policy reads:
------------------------------------------------------------------------
/etc/aliases is the source file for the system mail aliases (e.g.,
postmaster, usenet, etc.), it is the one which the sysadmin and postinst
scripts may edit. After /etc/aliases is edited the program or human
editing it must call newaliases. All MTA packages must come with a
newaliases program, even if it does nothing, but older MTA packages did
not do this so programs should not fail if newaliases cannot be
found. Note that because of this, all MTA packages must have Provides,
Conflicts and Replaces: mail-transport-agent control file fields.
------------------------------------------------------------------------

So a `newaliases` doing nothing is OK, but the aliases defined in that
file have to work. 

-- 
bye, Joerg
[Talking about Social Contract]:
We will not discriminate noone[...]
[So we discriminate anyone?]




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 16 Oct 2009 07:29:02 GMT) Full text and rfc822 format available.

Bug unarchived. Request was from Gerrit Pape <pape@dbnbgs.smarden.org> to control@bugs.debian.org. (Mon, 24 May 2010 12:39:07 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Mon, 24 May 2010 12:42:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Gerrit Pape <pape@dbnbgs.smarden.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Mon, 24 May 2010 12:42:05 GMT) Full text and rfc822 format available.

Message #321 received at 510415@bugs.debian.org (full text, mbox):

From: Gerrit Pape <pape@dbnbgs.smarden.org>
To: Archive Administrator <installer@ftp-master.debian.org>
Cc: 457318@bugs.debian.org, 510415@bugs.debian.org
Subject: Re: qmail-run_2.0.2_powerpc.changes is NEW
Date: Mon, 24 May 2010 12:40:10 +0000
On Sun, Mar 14, 2010 at 11:19:11AM +0000, Archive Administrator wrote:
> (new) qmail-run_2.0.2.dsc extra mail
> (new) qmail-run_2.0.2.tar.gz extra mail
> (new) qmail-run_2.0.2_all.deb extra mail
> sets up qmail as mail-transfer-agent
[...]

Hi, can you please say something about the status of the qmail and
related packages in NEW I uploaded in march?  Do you already have an
idea when the packages might be accepted or rejected?

Thanks, Gerrit.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Sun, 06 Jun 2010 19:15:11 GMT) Full text and rfc822 format available.

Acknowledgement sent to Gerrit Pape <pape@dbnbgs.smarden.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Sun, 06 Jun 2010 19:15:11 GMT) Full text and rfc822 format available.

Message #326 received at 510415@bugs.debian.org (full text, mbox):

From: Gerrit Pape <pape@dbnbgs.smarden.org>
To: Archive Administrator <installer@ftp-master.debian.org>
Cc: 457318@bugs.debian.org, 510415@bugs.debian.org
Subject: Re: qmail-run_2.0.2_powerpc.changes is NEW
Date: Sun, 6 Jun 2010 19:12:04 +0000
On Mon, May 24, 2010 at 12:40:10PM +0000, Gerrit Pape wrote:
> On Sun, Mar 14, 2010 at 11:19:11AM +0000, Archive Administrator wrote:
> > (new) qmail-run_2.0.2.dsc extra mail
> > (new) qmail-run_2.0.2.tar.gz extra mail
> > (new) qmail-run_2.0.2_all.deb extra mail
> > sets up qmail as mail-transfer-agent
> [...]
> Hi, can you please say something about the status of the qmail and
> related packages in NEW I uploaded in march?  Do you already have an
> idea when the packages might be accepted or rejected?

Hi, can you please say something about the status of the qmail and
related packages in NEW I uploaded in march?  Do you already have an
idea when the packages might be accepted or rejected?

> Thanks, Gerrit.




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Mon, 05 Jul 2010 07:31:32 GMT) Full text and rfc822 format available.

Bug unarchived. Request was from Gerrit Pape <pape@dbnbgs.smarden.org> to control@bugs.debian.org. (Wed, 17 Nov 2010 11:12:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Wed, 17 Nov 2010 12:39:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Gerrit Pape <pape@dbnbgs.smarden.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 17 Nov 2010 12:39:06 GMT) Full text and rfc822 format available.

Message #335 received at 510415@bugs.debian.org (full text, mbox):

From: Gerrit Pape <pape@dbnbgs.smarden.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: qmail-run_2.0.2_powerpc.changes is NEW
Date: Wed, 17 Nov 2010 12:37:58 +0000
----- Forwarded message from MAILER-DAEMON@a.mx.smarden.org -----

Date: 17 Nov 2010 09:18:34 -0000
From: MAILER-DAEMON@a.mx.smarden.org
To: pape-qn-f514329-@smarden.org
Subject: failure notice

Hi. This is the qmail-send program at a.mx.smarden.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<installer@ftp-master.debian.org>:
128.148.34.3 does not like recipient.
Remote host said: 550-mail for <installer@ftp-master.debian.org> only accepted from debian.org
550 machines
Giving up on 128.148.34.3.

<510415@bugs.debian.org>:
140.211.15.34 does not like recipient.
Remote host said: 550 Unknown or archived bug
Giving up on 140.211.15.34.

--- Below this line is a copy of the message.

Received: (qmail 24562 invoked by uid 1000); 17 Nov 2010 08:18:29 -0000
Message-ID: <20101117081829.24561.qmail@28743390445746.315fe32.mid.smarden.org>
Date: Wed, 17 Nov 2010 08:18:28 +0000
From: Gerrit Pape <pape@dbnbgs.smarden.org>
To: Archive Administrator <installer@ftp-master.debian.org>
Cc: 457318@bugs.debian.org, 510415@bugs.debian.org
Subject: Re: Bug#510415: qmail-run_2.0.2_powerpc.changes is NEW
References: <E1Nqlqh-0001vU-8K@ries.debian.org> <20100524124010.GB17784@smarden.org> <20100606191204.5663.qmail@d00d4463a1bc4d.315fe32.mid.smarden.org>
In-Reply-To: <20100606191204.5663.qmail@d00d4463a1bc4d.315fe32.mid.smarden.org>

On Sun, Jun 06, 2010 at 07:12:04PM +0000, Gerrit Pape wrote:
> On Mon, May 24, 2010 at 12:40:10PM +0000, Gerrit Pape wrote:
> > On Sun, Mar 14, 2010 at 11:19:11AM +0000, Archive Administrator wrote:
> > > (new) qmail-run_2.0.2.dsc extra mail
> > > (new) qmail-run_2.0.2.tar.gz extra mail
> > > (new) qmail-run_2.0.2_all.deb extra mail
> > > sets up qmail as mail-transfer-agent
> > [...]
> > Hi, can you please say something about the status of the qmail and
> > related packages in NEW I uploaded in march?  Do you already have an
> > idea when the packages might be accepted or rejected?
> 
> Hi, can you please say something about the status of the qmail and
> related packages in NEW I uploaded in march?  Do you already have an
> idea when the packages might be accepted or rejected?

No reaction or response to mails at all from ftpmasters within more than
eight months.  Obviously the packages are deliberately ignored.

----- End forwarded message -----




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Thu, 16 Dec 2010 07:31:23 GMT) Full text and rfc822 format available.

Bug unarchived. Request was from Gerrit Pape <pape@dbnbgs.smarden.org> to control@bugs.debian.org. (Tue, 29 Mar 2011 09:57:04 GMT) Full text and rfc822 format available.

Did not alter fixed versions and reopened. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Tue, 29 Mar 2011 09:57:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Tue, 29 Mar 2011 10:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Gerrit Pape <pape@dbnbgs.smarden.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 29 Mar 2011 10:09:04 GMT) Full text and rfc822 format available.

Message #346 received at 510415@bugs.debian.org (full text, mbox):

From: Gerrit Pape <pape@dbnbgs.smarden.org>
To: 510415@bugs.debian.org
Subject: Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Tue, 29 Mar 2011 10:00:09 +0000
On Thu, Aug 27, 2009 at 02:34:16PM -0700, Don Armstrong wrote:
> On Thu, 27 Aug 2009, Andreas Barth wrote:
> > 34215
> 
> With 4 people ranking 3 first, and Steve ranking it second, I believe
> the outcome is no longer in doubt, and so the CTTE has resolved that
> 
> 3. Qmail is to be allowed in to the archive after a patch to resolve
> the delayed bounces issue, where mail sent to an invalid recipient
> which a reasonable MTA is capable of knowing is invalid is accepted
> instead of being rejected at RCPT TO time. After upload, the process
> outlined in option #2 will take effect.
> 
> [From option #2]
> 
> Ftpmaster should perform standard NEW processing for licensing,
> copyright, and general packaging issues as normal. with the addition
> of an RC bug filed immediately to preventing normal transition for a
> period of at least a month after traversing NEW.

Hi, packages are in NEW since more than one year without any comments
from ftpmasters.  I don't think that's "standard NEW processing for
licensing, copyright, and general packaging issues as normal", isn't it?

Regards, Gerrit.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Tue, 29 Mar 2011 15:21:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Peter Madams <peter@madams.com>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 29 Mar 2011 15:21:07 GMT) Full text and rfc822 format available.

Message #351 received at 510415@bugs.debian.org (full text, mbox):

From: Peter Madams <peter@madams.com>
To: Gerrit Pape <pape@dbnbgs.smarden.org>, 510415@bugs.debian.org, debian-ctte@lists.debian.org
Subject: Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Tue, 29 Mar 2011 08:19:41 -0700
[Message part 1 (text/plain, inline)]
Congratulations Gerrit.  Almost there.  Thanks for your persistence.
-PeterM


On Tue, Mar 29, 2011 at 3:00 AM, Gerrit Pape <pape@dbnbgs.smarden.org>wrote:

> On Thu, Aug 27, 2009 at 02:34:16PM -0700, Don Armstrong wrote:
> > On Thu, 27 Aug 2009, Andreas Barth wrote:
> > > 34215
> >
> > With 4 people ranking 3 first, and Steve ranking it second, I believe
> > the outcome is no longer in doubt, and so the CTTE has resolved that
> >
> > 3. Qmail is to be allowed in to the archive after a patch to resolve
> > the delayed bounces issue, where mail sent to an invalid recipient
> > which a reasonable MTA is capable of knowing is invalid is accepted
> > instead of being rejected at RCPT TO time. After upload, the process
> > outlined in option #2 will take effect.
> >
> > [From option #2]
> >
> > Ftpmaster should perform standard NEW processing for licensing,
> > copyright, and general packaging issues as normal. with the addition
> > of an RC bug filed immediately to preventing normal transition for a
> > period of at least a month after traversing NEW.
>
> Hi, packages are in NEW since more than one year without any comments
> from ftpmasters.  I don't think that's "standard NEW processing for
> licensing, copyright, and general packaging issues as normal", isn't it?
>
> Regards, Gerrit.
>
>
>
> --
> To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> Archive:
> http://lists.debian.org/20110329100009.12165.qmail@c585e02509d04c.315fe32.mid.smarden.org
>
>
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Tue, 29 Mar 2011 15:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Tue, 29 Mar 2011 15:27:03 GMT) Full text and rfc822 format available.

Message #356 received at 510415@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: Gerrit Pape <pape@dbnbgs.smarden.org>, 510415@bugs.debian.org
Subject: Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Tue, 29 Mar 2011 08:15:09 -0700
On Tue, 29 Mar 2011, Gerrit Pape wrote:
> On Thu, Aug 27, 2009 at 02:34:16PM -0700, Don Armstrong wrote:
> > On Thu, 27 Aug 2009, Andreas Barth wrote:
> > > 34215
> > 
> > With 4 people ranking 3 first, and Steve ranking it second, I believe
> > the outcome is no longer in doubt, and so the CTTE has resolved that
> > 
> > 3. Qmail is to be allowed in to the archive after a patch to resolve
> > the delayed bounces issue, where mail sent to an invalid recipient
> > which a reasonable MTA is capable of knowing is invalid is accepted
> > instead of being rejected at RCPT TO time. After upload, the process
> > outlined in option #2 will take effect.
> > 
> > [From option #2]
> > 
> > Ftpmaster should perform standard NEW processing for licensing,
> > copyright, and general packaging issues as normal. with the addition
> > of an RC bug filed immediately to preventing normal transition for a
> > period of at least a month after traversing NEW.
> 
> Hi, packages are in NEW since more than one year without any comments
> from ftpmasters.  I don't think that's "standard NEW processing for
> licensing, copyright, and general packaging issues as normal", isn't it?

Has the patch to fix the delayed bounces issue been applied?


Don Armstrong

-- 
Cheop's Law: Nothing ever gets built on schedule or within budget.
 -- Robert Heinlein _Time Enough For Love_ p242

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




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Wed, 30 Mar 2011 14:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Gerrit Pape <pape@dbnbgs.smarden.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Wed, 30 Mar 2011 14:24:03 GMT) Full text and rfc822 format available.

Message #361 received at 510415@bugs.debian.org (full text, mbox):

From: Gerrit Pape <pape@dbnbgs.smarden.org>
To: Don Armstrong <don@debian.org>, 510415@bugs.debian.org
Subject: Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Wed, 30 Mar 2011 13:21:55 +0000
On Tue, Mar 29, 2011 at 08:15:09AM -0700, Don Armstrong wrote:
> On Tue, 29 Mar 2011, Gerrit Pape wrote:
> > Hi, packages are in NEW since more than one year without any comments
> > from ftpmasters.  I don't think that's "standard NEW processing for
> > licensing, copyright, and general packaging issues as normal", isn't it?
> 
> Has the patch to fix the delayed bounces issue been applied?

Yes, according to debian/changelog on Mon, 08 Mar 2010.

Regards, Gerrit.




Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Fri, 01 Apr 2011 12:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Mark Hymers <mhy@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 01 Apr 2011 12:39:03 GMT) Full text and rfc822 format available.

Message #366 received at 510415@bugs.debian.org (full text, mbox):

From: Mark Hymers <mhy@debian.org>
To: Don Armstrong <don@debian.org>, 510415@bugs.debian.org
Cc: ftpmaster@debian.org
Subject: Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 1 Apr 2011 13:17:52 +0100
On Tue, 29, Mar, 2011 at 08:14:21AM -0700, Don Armstrong spoke thus..
> What is the current status of this?

I've just checked the packages, and given the constraints of #510415, I
have accepted netqmail, dot-forward, fastforward, qmail-run and
qmail-tools.  I will shortly be filing RC bugs against each of these as
per #510415 to prevent their migration to testing.  Once I have those
bug numbers, I will update #510415 appropriately.

Mark

-- 
Mark Hymers <mhy at debian dot org>

"I'm so gorgeous, there's a six month waiting list for birds to suddenly
 appear, every time I am near!"
     Cat, Red Dwarf Series VIII - Back in the Red




Added blocking bug(s) of 510415: 620378 Request was from Mark Hymers <mhy@debian.org> to control@bugs.debian.org. (Fri, 01 Apr 2011 15:30:08 GMT) Full text and rfc822 format available.

Added blocking bug(s) of 510415: 620381 Request was from Mark Hymers <mhy@debian.org> to control@bugs.debian.org. (Fri, 01 Apr 2011 15:30:11 GMT) Full text and rfc822 format available.

Added blocking bug(s) of 510415: 620382 Request was from Mark Hymers <mhy@debian.org> to control@bugs.debian.org. (Fri, 01 Apr 2011 15:30:14 GMT) Full text and rfc822 format available.

Added blocking bug(s) of 510415: 620383 Request was from Mark Hymers <mhy@debian.org> to control@bugs.debian.org. (Fri, 01 Apr 2011 15:30:17 GMT) Full text and rfc822 format available.

Added blocking bug(s) of 510415: 620384 Request was from Mark Hymers <mhy@debian.org> to control@bugs.debian.org. (Fri, 01 Apr 2011 15:30:20 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org>:
Bug#510415; Package tech-ctte. (Fri, 01 Apr 2011 15:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Mark Hymers <mhy@debian.org>:
Extra info received and forwarded to list. Copy sent to Technical Committee <debian-ctte@lists.debian.org>. (Fri, 01 Apr 2011 15:45:03 GMT) Full text and rfc822 format available.

Message #381 received at 510415@bugs.debian.org (full text, mbox):

From: Mark Hymers <mhy@debian.org>
To: Don Armstrong <don@debian.org>, 510415@bugs.debian.org
Cc: ftpmaster@debian.org
Subject: Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 1 Apr 2011 16:42:25 +0100
On Fri, 01, Apr, 2011 at 01:17:52PM +0100, Mark Hymers spoke thus..
> I've just checked the packages, and given the constraints of #510415, I
> have accepted netqmail, dot-forward, fastforward, qmail-run and
> qmail-tools.  I will shortly be filing RC bugs against each of these as
> per #510415 to prevent their migration to testing.  Once I have those
> bug numbers, I will update #510415 appropriately.

Bug numbers are:

#620378
#620381
#620382
#620383
#620384

Thanks,

-- 
Mark Hymers <mhy at debian dot org>

"The first thing we do, let's kill all the Lawyers"
     Henry VI Part II, Shakespeare




Reply sent to Don Armstrong <don@debian.org>:
You have taken responsibility. (Fri, 01 Apr 2011 16:45:07 GMT) Full text and rfc822 format available.

Notification sent to Joerg Jaspert <joerg@debian.org>:
Bug acknowledged by developer. (Fri, 01 Apr 2011 16:45:07 GMT) Full text and rfc822 format available.

Message #386 received at 510415-done@bugs.debian.org (full text, mbox):

From: Don Armstrong <don@debian.org>
To: Mark Hymers <mhy@debian.org>, 510415-done@bugs.debian.org
Cc: ftpmaster@debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Date: Fri, 1 Apr 2011 09:34:55 -0700
On Fri, 01 Apr 2011, Mark Hymers wrote:
> On Tue, 29, Mar, 2011 at 08:14:21AM -0700, Don Armstrong spoke thus..
> > What is the current status of this?
> 
> I've just checked the packages, and given the constraints of #510415, I
> have accepted netqmail, dot-forward, fastforward, qmail-run and
> qmail-tools.  I will shortly be filing RC bugs against each of these as
> per #510415 to prevent their migration to testing.  Once I have those
> bug numbers, I will update #510415 appropriately.

Awesome; thanks Mark!

Just a heads up for those on -devel who had additional bugs that were
reported to the CTTE; these should be filed against the appropriate
qmail package if they are still an issue.


Don Armstrong

-- 
First you take a drink,
then the drink takes a drink,
then the drink takes you.
 -- F. Scott Fitzgerald

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




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sat, 30 Apr 2011 07:46:00 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 23 13:07:33 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.