Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]
Matthew Garrett wrote:
Anthony Towns <aj@azure.humbug.org.au> wrote:
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 --
But currently people have no idea what the underlying cause /is/, which
is certainly a communications issue.
The underlying cause for the complaints is that NEW isn't being processed.
The complaints are both that NEW isn't being processed and that there's
no communication.
There's no particular reason NEW isn't being processed -- people are
just busy doing other things; some of which are outside Debian, others
of which are related to getting the release out, or whatever else.
That's not, in my opinion, something Debian developers have any right to
ask for -- my day planner's my business, not yours.
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,
See, that's the thing, you _are_. You can tell, because you had to
explicitly refute the idea; it's the same as being able to tell you're
being offensive when you feel the need to say "no offense intended". And
sometime's that's necessary; but it's happening _continually_, which is
just tiresome and demotivating.
And remember, demotivation leads to indifference, indifference leads to
inactivity, inactivity leads bugs, and bugs lead to suff-er-ing.
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.
The sentence "I'm not suggesting that the ftp-masters are engaged in a
drug-fuelled orgy of depravity" seems conspicuous in its absence...
(Although, given James T. was out partying all last night with Steve L.,
maybe that's not so unreasonable...)
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)
TTBOMK, there are no greater concerns with the packages in NEW now than
there were, say, four months ago. Each of the ftpmasters have just had
higher priorities, within or outside of Debian, than processing the queue.
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.
Not really -- the question then becomes "How do you get that
consensus?", and that's hard -- if it weren't we'd have already replied
"REJECT: Your package has these problems, please fix them." The
question's then immediately, "How do we deal with the followup
question?" and there's no real answer to that.
There was a similar issue with the crypto-in-main question -- when the
crypto regs changed, we spent ages wanting to integrate crypto into our
OS, but not quite knowing how. Eventually, we got a group together to
look seriously at the issues, and work out what really was feasible, and
did it -- but that involved finding a specialist lawyer we respected,
having a few iterations working out all the potential problems and how
we'd address them, and a lot of time and effort, particularly on behalf
of ftpmaster. And that's *with* a specific "crypto-in-main" team made up
of non-ftpmasters.
That's time and effort that's not available now even for *standard* NEW
processing.
It'd be possible to prioritise increased communication, but that's YA
thing to do, leaving less time for even the things that're currently
being done.
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.
There are various scales of "awkward", ranging from "we might get sued
if we accept this, and we've no idea if we'd even have the law on our
side" to "gag, that's one long copyright file, I might read that after
breakfast instead". None of the packages are being ignored though.
It's hard to take this sort of discussion as anything but an attack on
ftpmaster, since there are plenty of teams in Debian that're even less
transparent and effective than us. But given how these sorts of
discussions affect ftpmaster, I'm pretty reluctant to want to inflict
them on anyone else.
(Cue the "if you can't stand the heat, get out of the kitchen" flames)
Cheers,
aj
Reply to: