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