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.conno...@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 <elecha...@gmail.com> wrote: > Le 18/11/15 14:34, Stephen Connolly a écrit : > > On Wednesday 18 November 2015, Emmanuel Lécharny <elecha...@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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
