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

Re: Implement major FSFS performance related changes in the experimental FSX format

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 30 Sep 2014 09:29:34 -0400

On 09/26/2014 12:34 PM, Stefan Fuhrmann wrote:
> On Fri, Sep 26, 2014 at 5:07 PM, Ivan Zhakov <ivan_at_visualsvn.com
> <mailto:ivan_at_visualsvn.com>> wrote:
>
> I think it would be fair to call a 'Consensus Approval' vote [1,2]
> for leaving
> the log-addressing feature in the trunk. In other words, it will
> be required
> at least three binding '+1' votes (and no vetos) to leave the code
> in trunk.
>
> It will be also assumed that:
> a) +1 votes could be presented only by folks who both understand
> the log-addressing feature and have reviewed the code.
> b) a concrete technical justification showing why the change is bad
> (allows data to be corrupted, negatively affects performance,
> etc. )
> should be provided for a '-1' vote.
>
> Effectively, this vote will be similar to our 3-vote policy for
> branches
> but made a little later.
>
> What do you think about this plan for vote?
>
>
> Hi Ivan,
>
> Not being Mike, here is my opinion anyway: I'm +1 on your proposal.
> In fact, I had planned to call for exactly that vote at some point mid-Oct
> (so I could complete work on the other bits e.g. svnfsfs before that).
>
> Due to the size of the features (plural), I think we should extend the
> voting period to at least 2 weeks. This will give people who are new
> to the code a chance to actually review it. I don't think there is any
> point in rushing a decision at this stage of 1.9 "slippage".
>
> -- Stefan^2.

I'm late to the party, but this all sounds great.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development
Received on 2014-09-30 15:30:09 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.