[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: Thu, 12 Jun 2008 13:33:05 +0200

Karl Fogel wrote:
> Branko Čibej <brane_at_xbc.nu> writes:
>> Karl Fogel wrote:
>>> "Justin Erenkrantz" <justin_at_erenkrantz.com> writes:
>>>> On Wed, Jun 11, 2008 at 1:12 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
>>>>> Sorry, I meant: I was addressing them as well as you, as there has
>>>>> sometimes been confusion over what "-1" means and whether it's the same
>>>>> as what "veto" means in other projects.
>>>> IMO, a "-1" is always a veto unless otherwise stated. -- justin
>>> Sure, as long as people remember that "veto" just means "strong
>>> objection and possibly (but rarely) forced vote".
>> Sorry, what? A veto on technical grounds is always a veto. This wasn't
>> a policy discussion; it was a technical issue. A vote on technical
>> issues to overturn a veto is, to put it mildly, a bit like political
>> interests overriding hard facts. Then the polar icecap melts. ...
> In the end, all consensus processes must have either voting or forking
> as a fallback. It's not like there's some third way. If an objection
> is technical, then the discussion to resolve it should be based on the
> technical issues -- but if that discussion were to fail to resolve it,
> then there isn't any magical solution available, other than voting.
> Some magical philosopher king is not going to show up and give everyone
> the answer. Barack Obama will not save your project.
> When I say "there is no such thing as a veto in Subversion", what I mean
> is that there is no unilateral right to make something happen or not
> happen against the will of a majority of developers. Some people
> apparently thought otherwise, but now they know better.
> A so-called "veto" or "-1" is just a way of stopping momentum and
> getting everyone to discuss something carefully; it would be ludicrous
> for it to mean "someone can prevent a change forever just by invoking a
> magic word". That would be silly: it would invite abuse and be an
> unsuccessful form of governance.
> I don't think you were advocating that, and so am not sure you actually
> disagree with what I was saying. But if you do disagree, please
> explain in detail how you envision a veto process working. As far as
> I'm aware, the way I described in this thread is the way we have in fact
> been doing things all along.

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.

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.

And on this note I hereby cast my non-technical-but-binding -1 on
mentioning any US presidential candidate, or the election race itself,
on this list. They're already oozing out of our ears. (shudder)

-- 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-12 13:49: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.