[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC,PATCH] Port libsvn_auth_kwallet to KDE3.

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Thu, 12 Jun 2008 19:03:50 -0400

Branko Čibej <brane_at_xbc.nu> writes:
> I don't remember a single instance of a vote to overturn a veto on
> technical grounds. Nor would I support such a vote. We've always
> discussed the matter and let the heftier arguments prevail. Sure we
> did vote on technical issues, but not to overturn a veto.

Please stop describing the easy case while pretending the difficult case
does not exist :-). We're talking here about the difficult case.

Obviously, if we reach consensus on what "the heftier arguments" are,
then there's no controversy: those arguments will naturally prevail.

The hard situation is when there is disagreement on which arguments are
heftier -- that is, when we cannot reach consensus, even after
everyone's presented their best arguments. In that case, there is no
monolithic "we" to "let" the heftier arguments prevail. Yet there still
must be a process for deciding what to do, and that process is voting.
I mean, what else is there?

The fact that you don't remember a single instance of this actually
happening just means that we all have pretty good technical jugdement.
<everyone pat self on back>. That's fine: these procedures are the
fallback. They don't have to get invoked to serve their purpose.

> IMO the only way to overturn a full committer's veto by vote is for
> the majority of full committers to vote to revoke the vetoer's
> full-commiter status, then ignore his veto afterwards as
> non-binding. But that's as political as it can possibly get.
>
> At least that's how I always understood a technical veto, unlike the
> procedural or, if you will, political kind, which is really just a
> vote accompanied by some flustered hand-waving and shouting.

Your distinction between technical and political decisions is spurious.
All sufficiently difficult decisions are political. Global warming is
political. Any time people disagree over what to do with a shared
resource -- whether it be a code base or a planet -- then they are in a
political situation. It may also be technical, but using that word
doesn't make the disagremeent go away, or change the procedures by which
disagreements get resolved.

So you're saying that when we are forced to vote to resolve a failure to
reach consensus, we can't just vote on the immediate question -- we also
have to kick out the person who forced the vote, if they lose? Come on.

I don't think we've ever followed the system you're proposing. It would
be much worse than the system I'm claiming we've been using, because it
would (apparently) require that a maintainer be voted off the island if
his "technical" veto were overridden. Why do that? Anyone who wants to
leave is free to, but there's no reason for us to turn a one-time
technical disagreement into a membership issue.

Meanwhile, the system I described:

   - Succeeds in resolving every dispute
   - Gives people a way to force reconsideration of a technical decision
     and (if necessary) force a vote
   - Does not force any issue to have higher stakes than those
     inherent in it originally

The reason this came was that some people were apparently under the
impression that one committer would somehow have the right to make
unilateral technical decisions even when a majority of other committers
felt differently. I don't think you were advocating that, but it's not
clear to me what positive method you were advocating -- unless it's the
one you described above, in which case -1 here...

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-13 01:04:08 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.