Summarizing: In a healthy project I believe that the only significant things that change between CTR and RTC are:
1) speed of commit (CTR is faster) 2) quality of master, not releases (RTC catches most issues before commit, CTR shortly after commit) I agree with others, nothing in the Apache Way says RTC is bad. Personally I believe CTR builds communities faster, but there are successful RTC projects. What really matters is managing the trade off above. Justification (mostly a repeat of what has been said already): I don't care what the website says. If I have a personal interest in a project succeeding then I will do everything in my power to ensure it succeeds. I assume the same is true for everyone else. This means that "mandatory" reviews are not required because they just get done by the people who care about project success. RTC does not guarantee reviews any more than CTR does, despite what a web page says. It merely guarantees a way period in which someone will give a patch a cursory glance. I'm not saying this is the normal RTC behavior, I'm merely saying this is all that is guaranteed. Fortunately the process doesn't change the way most people behave in a project, we can still trust them to do their reviews. Furthermore, there seems to be an assumption that CTR means complex or controversial code will be committed. In my experience this is not true. People don't like to waste time writing code that may be rejected. What I see is people discussing such changes, and providing psuedo code and then real code for review before committing to master. It saves time to get early review. Ross Sent from my Windows Phone ________________________________ From: Emmanuel Lécharny<mailto:elecha...@gmail.com> Sent: 11/18/2015 6:25 AM To: general@incubator.apache.org<mailto:general@incubator.apache.org> Subject: Re: RTC vs CTR (was: Concerning Sentry...) 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%7ced413f018da3415cdfc108d2f0240bc9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zFAIzqa9u1j6hu4m21erCSE9DRBOlcuEqRh5%2bRzHdZg%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%7ced413f018da3415cdfc108d2f0240bc9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=nuSlXYng%2bYfeOeEw7ce9NQ%2bKzgtrUXXZy6TselDnDUg%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%7ced413f018da3415cdfc108d2f0240bc9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1gOiqahAGrQ0u4S1oquKWypws0%2bW04dOgwnWoiW%2flMM%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%7ced413f018da3415cdfc108d2f0240bc9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=M1ST2%2f3jF4UCOpl1kHGXCf1TetxHWK145jg9PGvRBcs%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%7ced413f018da3415cdfc108d2f0240bc9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tMxwB8PqMZ6icAme1xnurv9jh7l3u2LU3CXPfaDTDsQ%3d> alternative. The important piece here is '...the lack of mandatory review...' > 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
