incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: RTC vs CTR (was: Concerning Sentry...)
Date Thu, 26 Nov 2015 11:47:52 GMT
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" <stevel@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 <cdouglas@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

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