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

Re: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

From: Greg Stein <gstein_at_gmail.com>
Date: Tue, 9 Jul 2013 22:54:55 -0400

On Tue, Jul 9, 2013 at 9:48 PM, Daniel Shahaf <danielsh_at_apache.org> wrote:
>...
> A veto not accompanied by a technical reason is invalid. I am seeking
> consensus on the dev@ list that no technical reason was given. No one
> is going to strip anyone's bits.

It's a slippery slope that you want to avoid. Very very much.

One of the things he said, "And API users want to see the most
interesting/unique value for every error, and wrapping with generic
codes is exactly working against that."

That's quite technical. Or simply saying "the serf code should remain
on top of the error stack" is technical.

It doesn't have to make sense to you, and you don't have to
acknowledge/understand his point. His veto still stands.

Again: you don't get to declare a veto "invalid", and the dev@ list is
not the place to seek consensus for that either. Take it to private@,
as I suggested, or work through the discussion. And if you want to
strip his veto, then you have to toss him from the PMC. As I said, PMC
Members have unilateral power. A majority or a supermajority doesn't
get to vote and say "bah. that veto is invalid." That throws out the
entire point of the veto system. So yes: you *are* talking about
stripping bits because that is your only path.

Further: this isn't a Rules game. Bert disagrees. Why don't you simply
work through the disagreement? I've seen PMCs played out as a Rules
game. It is horrible and destructive.

Cheers,
-g
Received on 2013-07-10 04:55:28 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.