> On 18 Nov 2015, at 13:34, Stephen Connolly <stephen.alan.conno...@gmail.com> > wrote: > > 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. 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. >
Interesting point. I'd personally take the view that if a patch broke a build or test then I'm prepared to revert that patch irrespective of when it went in. Where any voting is likely to come up is if there's a disagreement about whether a patch should go in; thinking of the most recent example of that I was involved in was https://issues.apache.org/jira/browse/HADOOP-12415 .. which was essentially "where in the classpath should zk.jar go" What RTC does do, however, is add an implicit way to veto something: ignore the patch. CTR removes that ability to ignore patches from committers, but still retains that option for non-committers -steve
