I concur. Chris' email is very insightful, and very well written. It is great food for thought, for each workflow approach.
Thanks, Chris. ... food.. thx... Happy Thanksgiving! -g On Nov 26, 2015 4:28 AM, "Steve Loughran" <ste...@hortonworks.com> wrote: > > This is really good essay on the whole topic. I don't think I've seen a > post on any asf list which uses both "existential threat" and "desiderata". > I also like the implication that RTC is a function of the complexity of the > team, rather than just the code. Every project I've worked on —open or > closed— had some bit of source that we were all scared of breaking. Those > bits need their oversight, no matter how —and it's recognition of that need > that matters more than how the changes are managed. > > +1 for encouraging CTR on startup, especially for projects starting out > with almost no code or people contributing. > > > On 26 Nov 2015, at 01:12, Chris Douglas <cdoug...@apache.org> wrote: > > > > 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. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org >
