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