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

Re: Technical committee resolution

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,

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


Attachment: signature.asc
Description: Digital signature

Reply to: