[Releasing] rethinking the branching scheme

[Oswald Buddenhagen]

On Fri, Feb 21, 2014 at 07:50:10PM -0800, Thiago Macieira wrote:
> Em sex 21 fev 2014, às 23:42:42, Oswald Buddenhagen escreveu:
> > yes. the merge is in the critical path of the alpha release. we can't
> > avoid it, and it isn't a big deal.
> > what makes a world of difference is the merge being in the critical path
> > of "branching". the difference between "we got a new branch, but
> > otherwise business as usual" and "all integrations are halted for the
> > better part of a week". between the start of the release process being
> > something that happens mostly in the background, and something that is
> > fairly disruptive to the normal flow (and rather stressful for those
> > involved) - actually quite the opposite of the intended effect of this
> > "simple" branching model.
> 
> From what I understand, the biggest pain is the actual merging. It doesn't 
> matter which branches are involved, merging causes trouble.
>
forward-merging is an almost-every day activity of development and
largely unproblematic.
it causes trouble only if the procedure surrounding the merge requires
disrupting the normal development activities.

> So I'm not convinced that changing the branching scheme makes is more
> sane. It will introduce more problems, because then we have 5.x to
> keep merging into 5.y and fixing integration problems for.
>
a) regular forward merges are *not* a problem
b) even if they were, we could lock down 5.x after the 5.y branch
creation (but that would be stupid due to a) and needing to re-target
lots of changes. otoh, keeping 5.x open means that changes landing there
may not be already in the next release).

> And as you clearly put it, those merges are now in the critical path
> of making releases.
> 
yes.
i also said that it is no big deal. the release team is perfectly
capable of waiting a few days after the branches were created. they have
enough other stuff to do.

> As long as 5.x isn't frozen for new commits, the proposed branching scheme 
> makes the situation worse for people doing merging.
> 
yes. i postulate that this is Not A Problem, especially as 5.x => 5.y
merges are unlikely to be conflicted.

> But if it is frozen, then the situation is exactly the same.
> 
it isn't. let's compare the concrete timings:

real branching:
- [write notification mail that we are starting the branching process]
- [lock down parent branches]
- [wait for integrations on parent branches to succeed or fail]
- create child branches (with a script): ~1 minute
- clone CI configs (with a script): ~2 minutes (yup, we'd need to put
  some effort into it to ensure that it is that painless)
- write notification mail that branches were created: ~2 minutes
- total time: ~5 minutes

- on top of that, the forward-merging from the previous stable branch
  needs to be done and integrated. that delays the release, but is
  asynchronous to development.

- [after two days, unlock parent branches]

downmerge "branching":
- write notification mail that we are starting the downmerge process
- lock down child branches
- wait for integrations on child branches to succeed or fail
- do forward merges
- [lock down parent branches]
- wait for integrations on parent branches to succeed
- do fast-forwards to child branches
- unlock child branches
- write notification mail that downmerging was completed
- total time: ~5 days (your estimate, probably realistic)

- [after two days, unlock parent branches]

the items in brackets are part of the "cherry-pick avoidance scheme" and
concern the parent branch only, so i didn't include them in the time
calculation (they don't concern the stabilization work relevant for the
release).

if we lock down 5.x in the new scheme (which is logically equivalent to
replacing stable in the current scheme), people can immediately retarget
for 5.y, so this doesn't impose a delay (beyond a few git operations and
a possible re-review. obviously, gerrit-side re-targeting would make
that somewhat smoother. we could have that).

do you now see the fundamental difference?