incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <>
Subject Re: RTC vs CTR (was: Concerning Sentry...)
Date Thu, 26 Nov 2015 01:12:11 GMT
RTC is regulation. That's not a synonym for control when it's
conflated with suspicion of people. Regulation is a set of deliberate
checks on a system.

Good regulation estimates (or reacts to) a system's natural excesses,
then attempts to constrain existential threats. It isn't a lack of
trust, but how trust is scaled. RTC can encourage review (where
oversight might be weak), throttle the pace of change (where sheer
volume might discourage volunteers and exclude individuals), and
identify code with a discouraging "bus factor" for attention or
removal (where an isolated contributor can't solicit any feedback).
Todd, Steve, Andrew, and others already covered other, intended

Bad regulation erroneously classifies the power structure as part of
the system, and threats to powerful people as existential threats to
the system. It preserves privilege at the expense of individual
initiative. RTC can mire committers in review, throttle the pace of
change artificially, and entrench project members behind an inertial
default. These unintended consequences create new existential threats
to a project, which either require subsequent regulation/monitoring or
they prove RTC to be worse than the diseases it remedied.[1]

In practice, RTC does all these simultaneously, and the community is
responsible for ensuring the implementation is effective, efficient,
and just. That balance isn't static, either. One chooses RTC not
because the code has some property (complexity, size, etc.), but
because the community does, at the time.

All that said: many, maybe most projects entering incubation should
try CTR, and adopt RTC if there's some concrete reason that justifies
added governance. If the culture requests reviews, enforces tests/CI,
members can keep up with changes, etc. then most probably won't bother
with RTC. If the project already has an RTC culture and they want to
keep it, we've seen that work, too. -C

[1] RTC/CTR isn't the last policy choice the project makes, either.
Allowing feature branches to work as CTR (complemented by branch
committers) can dampen the shortcomings of enforcing RTC on
trunk/release branches. Policies allowing non-code changes, etc. have
been mentioned elsewhere in the thread.

On Wed, Nov 25, 2015 at 12:39 PM, Greg Stein <> wrote:
> Boo hoo. Todd said it wasn't about control, and then a few days later said
> he was forcing people into doing reviews. So yeah: in his case, it *is*
> about control.
> Over the 17 years I've been around Apache, every single time I've seen
> somebody attempt to justify something like RTC, it always goes back to
> control. Always.
> -g
> On Wed, Nov 25, 2015 at 2:35 PM, Andrew Purtell <>
> wrote:
>> I have to completely disagree and find your assertion vaguely offensive.
>> > On Nov 25, 2015, at 12:32 PM, Greg Stein <> wrote:
>> >
>> > On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell <>
>> > wrote:
>> >> ...
>> >>
>> >> and inherited the RTC ethic from our parent community. I did recently
>> test
>> >> the state of consensus on RTC vs CTR there and it still holds. I think
>> this
>> >> model makes sense for HBase, which is a mature (read: complex) code base
>> >> that implements a distributed database. For sure we want multiple sets
>> of
>> >>
>> >
>> > I call bullshit. "complex" my ass. I've said it before: all software is
>> > complex, and yours is no more complex than another. That is NOT a
>> rationale
>> > for installing RTC. It is an excuse for maintaining undue control.
>> >
>> > -g
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message