Andreas Barth <a...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
