[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian



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

Attachment: signature.asc
Description: Digital signature


Reply to: