[Releasing] rethinking the branching scheme
frederik.gladhorn at digia.com
Mon Feb 24 19:26:29 CET 2014
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.
Senior Software Engineer - Digia, Qt
Visit us on: http://qt.digia.com
More information about the Releasing