[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Question for candidate Towns [Was, Re: DPL election IRC Debate - Call for questions]



Anthony Towns <aj@azure.humbug.org.au> wrote:

> 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.

As others have said, I don't think there's any right to expect an
individual to justify why they haven't been doing something. However, I
do think that there's an expectation that teams ought to say why things
aren't being done. "People are busy" is an entirely acceptable answer,
but instead we have rumours of the release team asking for NEW
processing to stop. I don't think that benefits anyone.

>> 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.

No. I don't believe that the ftp-masters are doing their job
inadequately. However, that doesn't mean that we should ignore any
situation where a team /does/ do their job inadequately. At what point
do we (as a project) step in and do something, and how do we deal with
that sort of situation without demotivating other teams? I think these
are difficult questions, but I think we need to find answers to them.

If a single group of people did significantly decrease the productivity
of the rest of the project for no good reason, I hope you'd agree that
something should be done. The fact that people are volunteers doesn't
mean that they can shirk responsibilities - if they do, that
responsibility has to be passed on to someone else.
 
>> 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.

Telling people that there is inadequate consensus about a package means
that they can either accept that they're not going to get that
consensus, or alternatively start doing something about gaining that
consensus. Failing to tell them that just leaves them puzzled. It's not
the job of the ftp-masters to gain that consensus, but I think it
/should/ be their responsibility to tell people that they don't think it
exists.

> 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.

Sure. How can that be improved?

> 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.

I've no grudge against ftpmaster. I think there are various teams within
Debian that could better communicate their activities, and my platform
makes it clear that I want to improve that. At the same time, I want to
work on reducing the entirely pointless complaints made against teams at
various points. As you point out, flamewars do nothing to improve
motivation or productivity.

-- 
Matthew Garrett | mjg59-chiark.mail.debian.vote@srcf.ucam.org



Reply to: