Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
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 <hamish@debian.org> <hamish@cloud.net.au>
Reply to: