Matthew Garrett wrote: Erm, <ftpmaster hat>, I guess.
Anthony Towns <aj@azure.humbug.org.au> wrote:As a concrete example, I don't think http://ftp-master.debian.org/new.htmlresolves the complaints about NEW and hence I don't think that the NEW issue is an example of a communication problem at all.http://ftp-master.debian.org/new.html failing to resolve the complaints about NEW doesn't demonstrate that it's not a communication problem. 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.
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."
The communication isn't perfect, but I don't think making it perfect would actually be a significant improvement.
3) My package has been sitting in the queue for ages and other packages have been processedThis 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.
Cheers, aj