On Fri, Mar 04, 2005 at 12:18:37PM -0800, Anthony Towns wrote: > Matthew Garrett wrote: > >3) My package has been sitting in the queue for ages and other packages > >have been processed > >This is a communication problem. > > No, this is a policy problem. Communication is easy: hit "M" for manual > reject, write a note, and it's all done. Or hit "P" for prod to write a > note to the maintainer with the possibility of accepting the package > anyway, or leaving it in the queue for later reconsideration. The issue > for packages like mplayer and hot-babe is that it's not clear that they > can be accepted, but it's also not clear that they should be rejected. > And until one or the other becomes clear, they're left in the queue. > > I actually think that's a good result: far better to keep track of the > problematic packages, than to just REJECT them with a reason like > "doesn't seem like a good idea" and have them randomly reuploaded later. > It also seems like a better idea to let packages that don't seem like > a good idea sit in the queue, rather than get uploaded and distributed > around the world.
I think there are actually five outcomes (or more) but only two of them are currently communicated: 1. Accepted; 2. Rejected; 3. Delayed because we're real busy but we'll get to it; 4. Delayed because we're not sure what to do with it (mplayer etc); 5. Delayed because we've stopped processing NEW to concentrate on another issue (like testing-security or the release or whatever). The latter three don't get communicated currently. There's rumours on debian-devel that NEW processing is actual on hold (by decision rather than by default) but that wasn't communicated. Of course it may be false and I don't expect to ftp-masters to have to refute every silly rumour, but some sign of life with regard to NEW processing would also be a positive sign. My example is the gEDA packages, which consists of a library and a bunch of apps distributed as separate source tarballs but always released together. New upstream versions almost always change the library soname due to API changes, and I've always reflected the soname in the binary package name, which then requires NEW processing. The package has been stuck in incoming for 2 months now. I asked for suggestions on a better approach on debian-devel, but the only replies I got told me that I must follow the letter of policy regardless of the circumstances. This relates to the better quality packaging you were talking about too. In the end I rearranged the packaging so that the NEW package wasn't needed, though I might be violating the letter of policy now. Just to avoid NEW processing delays each time. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
