Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
Anthony Towns <aj@azure.humbug.org.au> wrote:
> Matthew Garrett wrote:
>> Complaints about NEW can roughly be split into three catagories:
>> 1) It takes too long
>> 2) It isn't happening
>
> These are the same issue: it's a queue, packages uploaded now will be
> processed when NEW starts getting processed regularly again.
One is a special case of the other. Even while NEW is being processed,
there are occasional complaints that it takes too long.
>> This is (at least partly) a communication problem. When NEW processing
>> appeared to stall recently, most of the complaints I heard weren't that
>> it had stopped, but that nobody knew /why/ it had stopped.
>
> I think the "communication issues" are just a stand in for complaints of
> the underlying cause. If they weren't, I think the new.html page should
> be more of a solution -- to the point where people would be bringing it
> up and saying "Hey, there's this new page that gives you some idea of
> where you are in the queue! How cool!!!". There are two other bits of
> information people could ask for: "Why aren't individual ftpmasters
> spending time on Debian?", which I don't really think is anyone's
> business, and far more reasonably "Well, when will they be processed?".
> But the latter doesn't even have a known answer; and somehow I expect
> the response to "We don't know." would be "Well, you should! This is
> utterly unacceptable" not "Thankyou for communicating with us."
But currently people have no idea what the underlying cause /is/, which
is certainly a communications issue. I think this brings up another
question - to what extent should teams be expected to deal with problems
internally, and at what point should the project start thinking about
overriding them if they aren't seen to be working adequately? We have a
procedure for dealing with maintainers who don't look after their
packages, but nothing similar for people with other responsibilities.
(I'm not suggesting that the ftp-masters are doing their job
inadequately here, just that at the moment it's hard to make that
judgement - NEW may be slow because of real concerns, or because
everyone capable of processing it is currently engaged in a drug-fuelled
orgy of depravity. I know enough of you well enough that I assume the
first, but without more communication it's not surprising that people
will occasionally think that the second may be closer to the truth)
>> 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.
Sure. These are difficult cases, but even flagging them as "These
packages will not be accepted until there is clear consensus that they
should be" would be an improvement over them appearing ignored.
> 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'm certainly not suggesting that they be rejected out of hand, and
accepting them isn't the correct decision either. Currently, though,
it's impossible to tell the difference between "This package is awkward"
and "This package is being ignored". Making the distinction explicit
causes little harm.
--
Matthew Garrett | mjg59-chiark.mail.debian.vote@srcf.ucam.org
Reply to: