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 | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
