On Mon, Mar 10, 2008 at 10:45:25PM -0700, Russ Allbery wrote: > Anthony Towns <aj@azure.humbug.org.au> writes: > > You don't need to read my mind, you can read Ian's recent post on the > > topic, eg: > > http://lists.debian.org/debian-ctte/2008/03/msg00000.html > I'm not sure that Ian deciding that he doesn't think the tech-ctte is > functional or fast enough and hence isn't going to even give it an > opportunity to be functional is particularly persuasive. If the people on the committee aren't willing to use it, that's an easy and objective sign of dysfunctionality one way or another. Ian's also been on it for its entire existance, and as the proposer of the constitution is pretty much its designer, which is worth some weight too. > > Otherwise you could have a look at the ctte's open bugs, such as #436093. > Well, I actually agree with the sentiment expressed in that bug, namely > that it would be nice to resolve this without needing a formal vote. Which is fine, but it nevertheless hasn't been resolved, after almost a year; either from the tech-ctte's viewpoint, or the people involved, based on Raphael's and Andi's mails elsewhere on this list. > I don't think there's any specific governance problem here so much as a > lack of aggressive follow-through on closing issues. I'm not trying to say what the problem is -- I don't know what it is, and for all I know, I might be part of that problem. What I can say is that there *is* a problem, and that what we have been able to try hasn't fixed it. > Do you believe that this issue wasn't resolved because > the tech-ctte members have been serving for too long? And if so, why? No, I believe that the technical committee isn't working, and that without the accountability that results from other people being involved in tech-ctte decisions, and the new ideas and enthusiasm that results from new people becoming involved, it won't improve. And without both those things, even if it improves now, it will stagnate again in future. > > Or you could look at the tech-ctte's lack of ability to help resolve > > contentious issues in general, such as the conflict involving Sven the > > year before last, > I don't consider this a good example of anything, or a good basis on which > to make any future decisions. Sven's conflict with Frans, the d-i team and others is probably the most extreme example of a problem we've had to resolve. It was escalated to the DPL, to the tech-ctte, to DAM, to ftpmaster and others. Of all those, the tech-ctte was the least able to execute on its mandate, even in so far as simply saying "We're sorry, we're not going to resolve this for either of you" in a timely manner. > This was a special case in many directions, > a nasty social problem far more than a technical problem, A social problem without technical aspects doesn't much matter to Debian; if it doesn't affect anything technical we really can leave it to the people concerned. Once it starts having technical aspects, the tech ctte's relevant in that it has the ability to decide which way the technical aspects will go, and will often be invoked to decide on those technical aspects, and indirectly to end up choosing who's "best" in the social conflict. Not being able to at least resolve the technical disputes, whether that be "is this patch going to be applied?" or "who's maintainer of this package/area?" or "how should we determine whether a patch is to be applied/who's maintainer of this package/areas?", means the ctte isn't doing the job it's there for. And conversely, if it can only decide issues where there's no nasty social issues and everyone just wants a decision, you might as well replace it with a coin toss. > > or the tech-ctte's involvement in technical improvement of Debian before > > a conflict exists. > Well, with my Policy delegate hat on, I'd certainly welcome more help in > that area, but on the other hand I'm not sure I see any specific need for > the tech-ctte as such to get involved. There's two reasons. One is for the health of the committee itself: if you don't get practice resolving technical issues when there isn't a conflict, you're going to have a hard job doing so when there is. The other is simply that it's one of the committee's constitutional jobs: "decide on any matter of technical policy". Since the committee hasn't ever done that, it's been picked up by the policy team, release managers and others, with a fair amount of success (otherwise Debian would've been screwed long ago), but it's the constitutionally appointed body that should have those teams' back on policy issues. > For example, there are currently insufficient Policy proposal reviewers > active on debian-policy to even reach seconding thresholds on anything > other than the most obvious or important proposals. There are six ctte members, and probably there should be eight; none of us (with the exception of Manoj who's policy editor/maintainer anyway) are trying to babysit policy changes, and the comments we do make aren't due to our involvement in the ctte. How does that make sense? If you already have a bunch of networking experts, don't you expect them to be involved in planning your network architecture, not just resolving arguments once they've reached the bar fight stage, and offering ideas by the water cooler when they're not otherwise occupied? > > Or you could look at the value of past decisions made by the ctte, via > > the ctte web page www.debian.org/devel/tech-ctte. > What that page says to me is that people aren't using the tech-ctte. No, that's not true; that page doesn't include times when people have tried to pass decisions to the technical committee, and the committee hasn't managed to come up with an answer at all. That page is the committee's successes such as they are; it ignores its failures. > In > part, I think that's actually a triumph of other problem resolution > mechanisms. That Debian works at all is a triumph of other resolution methods, because the technical committee isn't actually one of our useful resolution methods. Seriously: compared to where we are right now, we would be no worse off if we removed the committee entirely. > We resolve most of our problems through significantly less > confrontational methods than a tech-ctte vote. Like a package hijack? Or a BTS war or entry in $gFuckheads? Or an RM edict? Or an ftpmaster tweak to dak? Or calling people idiots on mailing lists? Or a listban? Or a general resolution? Or forking? Or just letting the maintainer do whatever they want? Many of those don't seem less confrontational to me. > However, to the degree > that the paucity of decisions is due to a lack of confidence in the > tech-ctte, I agree that's a problem that would be nice to fix. You say that like the lack of confidence isn't justified. > Judging from the current tech-ctte bug queue, it doesn't look to me like a > lot of people are trying to use it to make decisions. When people give up on the tech-ctte or it becomes no longer relevant, the bug gets reassigned elsewhere, and isn't included on the page. > This makes it sound like you think there are specific people on the > tech-ctte who shouldn't be there and people who are not on the tech-ctte > who should. Is that the case? I could make a case for removing any or all of the current members, including myself. I don't think I could make a successful case for removing any of the ctte without them either deciding they agree and resigning, or them having been completely absent for months on end. There are definitely people outside the committee who are in general equally capable as those currently on it, and who are more capable in specific areas. I don't have anyone in particular in mind, but I would be more comfortable making suggestions if I thought that it'd be for a limited period (just in case they turn out crazy), or that other positions would open up predictably (so that it wasn't just a one off "let's add some people" without being a part of ongoing revitalisation. Compare it to the release team: since 1998, we've had Dale, Richard, me, Joey, Steve, Colin, JoeyH, Andi, Mark, Luk, Martin, Dato, Neil, Pierre, Phillip, Julien, and Dan all involved, and some I've forgotten I'm sure. That's for a role that was, in 1998, handled by one person. For the eight person technical committee, there's been Ian, Klee, Dale, Guy, Raul, Manoj, Wichert, Bdale, Steve, Andi and me. Replacing the longest serving member with someone else makes it easy to get new ideas and knowledge into the committee, and avoid having an aristocracy/priesthood/whatever of developers who think they're above the rules everyone else abides by, without having to criticise the existing members, either directly if you need a vote for their removal, or by implication if you just have to pick whoever you're replacing. > > I've brought problems before the technical committee in the past -- both > > what should be done in response to the "editorial amendments" GR [0], > > [0] http://lists.debian.org/debian-ctte/2004/04/msg00009.html > > http://lists.debian.org/debian-ctte/2004/06/msg00033.html > It doesn't look to me like you successfully brought this problem before > the tech-ctte, actually, although that may be nit-picking. It was discussed for two or three months, and a vote was attempted, but couldn't be agreed on; even to the point of saying "this is not an issue that the committee is empowered to resolve", which was one of the points being argued, and would have been helpful if resolved. > > [2] http://lists.debian.org/debian-ctte/2004/06/msg00033.html > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=97671#156 > Here, the tech-ctte specifically voted that precise bug severities were > not a technical issue and they weren't interested in taking this on. I'm > pretty sympathetic, as that whole thing looked like a tempest in a teapot > to me. So in that case, there was a dispute over whether 97671 was an RC bug or not, which was a dispute between: * the maintainer of the package who wanted complete control over how his bug page appears * the release manager who wanted control over what's RC and what's not And could have been resolved by: * the bugs.debian.org maintainers having the final say * the technical committee resolving the dispute * the DPL magically saying something * general resolution At the point at which it made it to the tech ctte, it was a dispute between developers who's authority overlapped -- Branden's as package maintainer, mine as RM/debbugs maintainer. The debbugs maintainers did not wish to decide -- either's fine as far as bugs.d.o is concerned. The DPL isn't really authorised to resolve arguments like that -- either person could just ignore their advice. The tech ctte at the time palmed that off noting that there was a technical issue, but because there was also some process stuff and they couldn't decide or agree on what the technical issue was, someone else could deal with it. > I'm not seeing the compelling justification here for a change in the > composition of the tech-ctte based on lack of action on a dispute over > whether a bug that everyone agreed wasn't RC should be either serious or > important. Again, it's justification that the ctte is and has been dysfunctional. > > [3] http://lists.debian.org/debian-ctte/2006/02/msg00002.html > I gotta say, I'm not seeing any of these ideas as horribly compelling > either (particularly the rotating chair; I don't see the point unless > Bdale isn't doing a good job or wants to hand it off to someone else). I don't think it's a matter of Bdale doing a good job; I don't think anyone else on the committee could do a better job. The point of the rotating chair wasn't to improve the chair, it was to have a reason for the chair to want to resolve issues in a timely fashion, eg getting all the issues that were open before you were chair closed by the time you have to pass it on. The chair also has an extra vote, having that rotate helps keep everyone involved on an equal footing, which is useful in itself. The same thing applies to membership of the ctte in both cases. As it happened, we only rotated twice -- from Ian to Steve and from Steve to Bdale. Steve tried quite hard to get a bunch of stuff resolved, but didn't end up with enough time. Since then, we've had a few bursts of energy, but otherwise mostly just tapered off. I'm not sure if the term "a good job" is all that applicable: the tech ctte chair can't do all that much, and Bdale's not doing anything wrong atm. But if it's good that people don't have confidence in the tech ctte, that the tech ctte can't deal with issues brought before it unless they're trivial and whoever brings the issue really pushes for a resolution, that the ctte is only reactive and doesn't look at issues without being asked, and that as a result almost everything is dealt with outside the committee, I guess that works. But then, if that's what we expect from the committee, why have a committee at all? Would we be any worse off if all the current bugs were reassigned to their respective maintainers, and all the historical bugs had just been left up to the maintainers, with maybe BTS wars being blocked by debbugs admins, package hijacks being decided by ftpmaster, etc? I don't think we would be worse off, and things would probably go easier and quicker if we skipped using the committee at all. That's what I mean by it being dysfunctional. Would we be better off if we had a body other than ftpmaster/debbugs/RM/DSA/etc could (and would) resolve disputes? I think we would. Most of those groups would prefer to be focussed on their technical issues, rather than having to also decide when a maintainer or developer is being a jerk and needs to be overruled, at least in my experience. And it's good if there's someone around who can overrule those groups themselves. Having the technical committee undertake that role effectively and competently would make life a bunch easier on those teams, IMO. > (2) here is again a question of follow-through, and I don't see how your > proposal addresses that. The problem again is that someone has to do > work, and you can't, in general, find people to do work by doing > governance shuffling. Eh? You can _only_ find people to do work if you can transfer the ability to do work from people who aren't doing it, to someone else. Being able to change who does the work isn't a sufficient condition, it's a necessary one. > I think you've identified some clear issues with the tech-ctte, namely > it's underutilized and it has problems with follow-through and closure. That it's underutilised is a consequence of its problems. That other groups are forced to deal with arguments that should be within the technical committee's remit is also a consequence of its problems. That there is no mechanism for people outside the committee to hold it accountable is a problem even if the committee were currently working perfectly. Cheers, aj
Attachment:
signature.asc
Description: Digital signature