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?
[1] http://www.apache.org/foundation/voting.html
[2] http://www.apache.org/foundation/glossary.html#ConsensusApproval
--
Ivan Zhakov
Received on 2014-09-26 17:08:35 CEST