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

Re: Time to branch 1.9

From: Branko Čibej <brane_at_wandisco.com>
Date: Thu, 06 Nov 2014 03:54:00 +0100

On 06.11.2014 00:03, Daniel Shahaf wrote:
> Branko Čibej wrote on Wed, Nov 05, 2014 at 06:32:25 +0100:
>> On 04.11.2014 17:58, Branko Čibej wrote:
>>> You still have, and always will have, the option to raise a veto. With
>>> arguments. About specific problems in the code. I've asked you to do
>>> that uncountable times. So now please don't try to hide behind
>>> community decisions and raise that veto already, so that we can
>>> discuss it and bring this sad state of affairs to an end.
>> Just to be clear: A vote would not in any way change your, or anyone
>> else's, opinion of the log-addressing feature; we'd get some +1 votes
>> and some -1 votes, and maybe the vote would pass or maybe not. But it
>> would not solve any real problems.
>>
>> Compare this to our backport voting, where -1 /is/ a veto, with all the
>> consequences and requirements to make it valid.
>>
>> That is why I said that a vote makes no sense for code that's already on
>> trunk; but a veto does.
> Agreed, let's focus the disussion back on specific technical problems.
>
> "We should have a vote because we decided to" is correct, but it's one
> level too meta. We wanted a vote to solicit review; so, instead of
> calling a vote, let's cut to the chase and directly solicit review.
>
> I suggest that Stefan starts a [CALL FOR REVIEW] thread, pointing out
> that the feature is no longer a moving target, and asking (a) anyone
> with outstanding technical concerns to point them out; and (b) anyone
> who has reviewed the feature and believes it is release-quality, to
> state so explicitly.
>
> Such a thread would achieve what the vote was meant to achieve, I think.

I couldn't agree more.

-- Brane
Received on 2014-11-06 03:54:35 CET

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.