typo s/every/revert/ If you do CTR and there are lots of vetos... which can happen if the reviews are requesting rework or changes... then there would need to be a lot of revert commits to revert the commits that were vetoed.
Thankfully in CTR mostly the case is you just commit the rework rather than revert the commit. The only case where you want to revert the commit is the case of compromised IP where the revert is saying "actually this IP is not correctly assigned" On 18 November 2015 at 17:02, Ross Gardler <ross.gard...@microsoft.com> wrote: > 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 > > > > >
