[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: Branko ─îibej <brane_at_xbc.nu>
Date: Fri, 13 Jun 2008 01:46:52 +0200

Karl Fogel wrote:
> 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.

That's how I've always understood the system. And why everyone jumps up
and takes notice when a veto pops up. To me the fact that we've only had
one case of revoking commit access, and that wasn't related to a veto,
just means that we do a pretty good job of a) swapping arguments and b)
granting full committer status.

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

Since we've never had to outvote a veto (in one way or another), I think
we do have fairly good positive methods in place. And I'm somewhat
confused because what you're proposing boils down to: "it's a veto but
it's not really a veto unless we all agree that it's a veto". I'd much
rather not use the word "veto" at all in that case, and substitute
"flustered hand-waving and shouting" instead. Or explicitly say, for
example, that "a veto can only be overridden by a qualified majority
vote of full committers" -- checks and balances, bla bla.

At the end of the day, if disagreements about technical decisions are
violent enough to cause an overriding vote, don't you think that whoever
raised the veto and had subsequently been stomped on would leave and/or
fork anyway?

-- Brane

---------------------------------------------------------------------
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:47:37 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.