incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Frovarp <rfrov...@apache.org>
Subject Re: RTC vs CTR (was: Concerning Sentry...)
Date Wed, 18 Nov 2015 17:08:21 GMT
On 11/18/2015 09:20 AM, Stephen Connolly wrote:
> On 18 November 2015 at 14:24, Emmanuel Lécharny <elecharny@gmail.com> wrote:
>
>> Le 18/11/15 14:34, Stephen Connolly a écrit :
>>> On Wednesday 18 November 2015, Emmanuel Lécharny <elecharny@gmail.com>
>>> wrote:
>>>
>>>> Le 18/11/15 11:31, Stephen Connolly a écrit :
>>>>> I believe the issue here is that with CTR it is very easy to miss the
>> 72h
>>>>> lazy consensus voting (with an assumed +1 absence any votes cast) that
>>>> most
>>>>> CTR projects operate under... and thus it can also be very easy to miss
>>>> the
>>>>> fact that there are reviews going on (and I am being generous here, I
>>>>> suspect that a lot of CTR commits are only reviewed within the 72h by
a
>>>>> blind man on a galloping horse)
>>>> I'm not sure why you are correlating commit reviews and a 72h vote...
>>>> They are two really different things.
>>> When I last read up my understanding is that CTR operates as if there is
>> a
>>> vote for each commit.
>> http://www.apache.org/foundation/glossary.html :
>>
>> *Commit-Then-Review*<
>> http://www.apache.org/foundation/glossary.html#CommitThenReview>
>>      (Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code
>>      changes which permits developers to make changes at will, with the
>>      possibility of being retroactively vetoed
>>      <http://www.apache.org/foundation/glossary.html#Veto>. C-T-R is an
>>      application of decision making through lazy consensus
>>      <http://www.apache.org/foundation/glossary.html#LazyConsensus>. The
>>      C-T-R model is useful in rapid-prototyping environments, but because
>>      of the lack of mandatory review it may permit more bugs through in
>>      daily practice than the R-T-C
>>      <http://www.apache.org/foundation/glossary.html#ReviewThenCommit>
>>      alternative.
>>
>> The important piece here is '...the lack of mandatory review...'
>>
>>
>>  From the same glossary:
> Lazy consensus
>> (Also called 'lazy approval'.) A decision-making policy which assumes
>> general consent if no responses are posted within a defined period. For
>> example, "I'm going to commit this by lazy consensus if no-one objects
>> within the next three days." Also see Consensus Approval
>> <http://www.apache.org/foundation/glossary.html#ConsensusApproval> , Majority
>> Approval <http://www.apache.org/foundation/glossary.html#MajorityApproval>
,
>> and the description of the voting process
>> <http://www.apache.org/foundation/voting.html>.
> <http://www.apache.org/foundation/glossary.html#LazyConsensus>
>
> So Lazy consensus is a voting process... if the code was committed more
> than three days ago, then there must have been a successful vote for
> committing that code... it was a lazy vote because there was no explicit
> [VOTE] thread.
>
> My point is that when I see people arguing for RTC over CTR what I maintain
> they are actually arguing over is the lazy consensus voting of each commit.
>
> People who want RTC really do not want lazy voting.
> People who want CTR really want lazy voting.
>
> I suspect that RTC with lazy consensus would be just as good an option for
> Greg and just as bad an option for Tony
>
> I also suspect that (in a parallel universe where the mess of revert
> commits could be magically resolved) CTR without lazy consensus would be
> just as good an option for Tony and just as bad an option for Greg.
>
> *My* point is that it is the lazy consensus that people are arguing about.
>
> CTR works best with lazy consensus (as there is the whole mess of
> reverting... but you'd only do that for commits that fail on the code
> provenance issue... so in practice it's not really anything even close to a
> big deal)
>
> RTC works best with non-lazy consensus and is acceptable with lazy
> consensus.
>
> In my day job, we use a sort of RTC with lazyish consensus...
> It helps that all our stuff happens on DSCMs where we can just commit away
> to our own branch until we are ready to merge.
> We then flag the merge request for review... if you have 2 positive reviews
> and no negative reviews in 12 hours, merge away... if you have 1 positive
> review and no negative reviews after 12 hours, merge away... if you have no
> reviews after 1 week, merge away
>
>

Isn't the RTC that is being described actually lazy consensus as well? 
If I submit, you review and apply, where is the active decision from the 
rest of the PMC? If it has been committed, presumably two people have 
agreed, but they need not be PMC and two people doesn't count as a 
successful vote. You at least need a third, and a option for others to 
disagree.

So my guess is that RTC is being done as a lazy consensus all of the time.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message