On Wed, Nov 25, 2015 at 3:39 PM, Greg Stein <gst...@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'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
step... what happens if releases are frequent (i.e. approaching
continuous?).

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

I don't give a whit about 'control issues' (perceived or real, doesn't
matter).  Anything I commit may be reverted.  I'm fine with that.  I
don't presume to control anything.  And if somebody wants to try to
control me -- all I can say is: good luck with that.  :-P

What I care most about is languishing patches.  Whether they come from
team members or drive by contributors, doesn't matter.  That's
harmful.  Git, and in particular, GitHub, makes them less harmful, but
they are the root problem not whether the process is
Commit-Then-Revert or Post-Then-Ignore.

If most communities in the Hadoop ecosystem use RTC, I don't care
UNLESS there is evidence of them not being responsive to patches.  For
quieter communities (including apparently BigTop), RTC could lead to
problems, and CTR is arguably more appropriate.  I'm fine with that
too.

- Sam Ruby

P.S.  My personal preference remains CTR.  I would much rather be
reverted with an explanation than to be ignored without one.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to