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 desiderata. 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 <gst...@gmail.com> 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 <andrew.purt...@gmail.com> > wrote: > >> I have to completely disagree and find your assertion vaguely offensive. >> >> > On Nov 25, 2015, at 12:32 PM, Greg Stein <gst...@gmail.com> wrote: >> > >> > On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell <apurt...@apache.org> >> > 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: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
