incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: RTC vs CTR (was: Concerning Sentry...)
Date Wed, 18 Nov 2015 14:00:17 GMT

> On 18 Nov 2015, at 13:34, Stephen Connolly <> wrote:
> On Wednesday 18 November 2015, Emmanuel Lécharny <>
> 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   .. 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

View raw message