[Releasing] rethinking the branching scheme

[Frederik Gladhorn]

Fredag 21. februar 2014 19.50.10 skrev Thiago Macieira:
> 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. 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. And as you clearly put it, those
> merges are now in the critical path of making releases.
> 
> As long as 5.x isn't frozen for new commits, the proposed branching scheme
> makes the situation worse for people doing merging.
> 
> But if it is frozen, then the situation is exactly the same.

There is a script in qtrepotools, git-qt-merge-mainlines (in Python, for my 
sanity, sorry, I don't speak Perl that well) to merge all modules of a qt5.git 
checkout. It's really simple and unless there are conflicts it's no work. I 
would claim that with more branches we don't have much more work since it's 
pretty much automatic and just requires staging in gerrit in the end.

What is problematic is:
- getting merges to go through CI in a narrow time window (needed with the 
current scheme, not so much with 5.x branches)
- reverse dependencies: we test qtdeclarative when changing qtbase and the 
other way around. This is generally a good thing as it prevents us from 
messing up the other repo unintendedly. The problem is that we keep on having 
dependencies on changes both directions over time, which means we first end up 
having qtbase depend on a newer qtbase, that works out for the normal 
integration. At a later time the same happens the other way around, now we're 
stuck for merges. Disable the reverse dependencies after noticing and try to 
get the whole thing though. With making that instead just the creation of new 
5.x branches off of the dev/master branch we don't have this problem.

-- 
Best regards,
Frederik Gladhorn
Senior Software Engineer - Digia, Qt
Visit us on: http://qt.digia.com