[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: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Tue, 30 Sep 2014 21:01:55 +0400

On 26 September 2014 20:34, Stefan Fuhrmann
<stefan.fuhrmann_at_wandisco.com> wrote:
> On Fri, Sep 26, 2014 at 5:07 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>> Mike,
>> > At a minimum, the community needs to establish that this feature and its
>> > side-effects are understood by more than just the one smart guy that
>> > wrote
>> > it and the other smart guy who isn't a fan. Then, those who understand
>> > the
>> > feature and its side-effects need to publicly weigh in on both the value
>> > and the timing (1.9, FSFS rather than FSX, etc.) of the change.
>> > How do you manage this discussion in the simplest way possible? Call
>> > for
>> > a formal vote on removing the feature, asking that the extreme +1/-1
>> > votes
>> > be presented only by folks who both understand the feature and have
>> > reviewed
>> > the code. (Seems only fair to allow the status quo to remain the
>> > default
>> > action.) Give the vote at least 72 weekday hours to allow time for code
>> > review, and then put this topic behind you/us and move on.
>> Since no one objected to this approach, I assume that there is a lazy
>> consensus and I'm going to start a formal vote regarding the
>> log-addressing feature early next week.
>> 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".

It seems that you started to change fsfs code actively, so I postpone
creation of the formal vote until the code and data format (!) will
be "stabilized" again.

Please let me know when you finish.

Ivan Zhakov
Received on 2014-09-30 19:02:42 CEST

This is an archived mail posted to the Subversion Dev mailing list.