incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <Ross.Gard...@microsoft.com>
Subject RE: RTC vs CTR (was: Concerning Sentry...)
Date Wed, 18 Nov 2015 17:02:00 GMT
I agree, mostly, with your mail Stephen, but I wonder about the reference you make to "the
mess of every commits". Do you really see that?

If you do see it I suspect the project has a problem. In my experience reverts are rare. We
prefer people improve what is there rather than revert what they don't like. It's not always
possible so occasional reverts are likely, but you shouldn't be seeing lots of reverts.

Sent from my Windows Phone
________________________________
From: Stephen Connolly<mailto:stephen.alan.connolly@gmail.com>
Sent: ‎11/‎18/‎2015 7:21 AM
To: general@incubator.apache.org<mailto:general@incubator.apache.org>
Subject: Re: RTC vs CTR (was: Concerning Sentry...)

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.
>
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=TL9a3HXjrIU7ntwJs8RqxDraGBtcz%2bzbjJACbgh%2f9LM%3d
:
>
> *Commit-Then-Review*<
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23CommitThenReview&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3qCZYrBRMPK4j7qZpzlgHAmNW9L%2bGQp2QYgPjeDzm%2bI%3d>
>     (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
>     <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23Veto&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Bwshvacajf1bpiCM%2bmzVxo0Ow8DgsidGmOhW5dLKSEY%3d>.
C-T-R is an
>     application of decision making through lazy consensus
>     <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23LazyConsensus&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7GegAJIQoysXF8P6q2pb17XIDqDaNo3G48W0uYME9%2bk%3d>.
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
>     <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23ReviewThenCommit&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=WwxXkFBwIeUhUMcao%2ff4kffNgSy8T8eN1amIhOiv%2fvo%3d>
>     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
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23ConsensusApproval&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9zElQFn5AfUKcvECMlo4S0H1eN5NTgBy6vDQSYKg2gQ%3d>
, Majority
> Approval <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23MajorityApproval&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Vqx1H5WCtepubszM0t%2fS9XA35rtAgl0c9rlqEhpWe5U%3d>
,
> and the description of the voting process
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fvoting.html&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=hAzlCwh2fWPuhffXTh0pWKjcaEgZQpFEcrchKNJxPp0%3d>.

<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23LazyConsensus&data=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7GegAJIQoysXF8P6q2pb17XIDqDaNo3G48W0uYME9%2bk%3d>

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


>
> >  It's a really lazy vote though as the vote passes if
> > nobody comments on the commit after 72h... And personally I do not see
> much
> > value in post-hoc votes... What are we going to do, rewrite history? But
> as
> > I understand the "vote" is so that the code in source control can be
> > covered by the legal umbrella despite it being outside of a formal source
> > release.
>
> AFAIU, it means it's very much a C[-T-R] and not a C-T-R...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message