incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject RE: RTC vs CTR (was: Concerning Sentry...)
Date Wed, 18 Nov 2015 16:54:38 GMT

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

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


Sent from my Windows Phone
From: Emmanuel Lécharny<>
Sent: ‎11/‎18/‎2015 6:25 AM
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 <>
> 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.

    (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
C-T-R is an
    application of decision making through lazy consensus
    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

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:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message