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 Wed, 25 Nov 2015 21:51:21 GMT
On Wed, Nov 25, 2015 at 3:27 PM, Sam Ruby <rubys@intertwingly.net> wrote:

> On Wed, Nov 25, 2015 at 3:39 PM, Greg Stein <gstein@gmail.com> wrote:
> >
> > 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.
>
> Strongly disagree.  If you say 'every', all it takes is one counter
> example to disprove the assertion.  Here is a counter example:
>
>
> https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+infrastructure-puppet+repo
>
> It is not a hypothetical example from the distant past.  It is a live
> example which seems to work well.  I've witnessed it being used for
> single line patches (a removal of a line, in fact) in a YAML file.
> Gavin created a branch, made a patch, pushed it, and Daniel merged it.
> Not for provenance reasons.  Or for control reasons.  But to ensure a
> second set of eyes looked at the change and evaluated whether or not
> there may be some unanticipated side effect.
>

I disagree. It *is* for control reasons. Infra can't allow a patch to be
deployed willy-nilly, or shit goes wrong. Fast.

Infra is not building a software product. They are maintaining live
systems. Control is absolutely needed.

Their entire repository is like a release stabilization branch. It needs to
be vetted before release.

I'll propose a thought experiment.  We seem to agree that there is
> room for teams to impose some form of RTC on branches that are to be
> released "soonish" (for some value of "soonish").  Let's take the next
>

Yes, I call those branches "owned by" or "personal branch of" the RM, who
decides to apply his/her rules on what is allowed onto the branch. At some
point, the RM cuts a release and the community votes on it.

One RM might allow any change. Another RM might require (3) +1 votes for
any change to be applied. Yet another refuses all change, and only applies
changes themselves.

step... what happens if releases are frequent (i.e. approaching
> continuous?).
>

Don't shut down trunk/master for product development. If the RMs want to
push my work into the releases each week, then great. I'll help them, under
the rules they set. If I find their release rules too onerous, then I'll
start my own release under Apache's "any committer can be an RM" and hope
for (3) +1 votes on the result.


> That's essentially what the infrastructure team is faced with.
>

It's not a product. They are solving a very different problem.

>...

Cheers,
-g

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