[Releasing] rethinking the branching scheme

[Frederik Gladhorn]

Onsdag 19. februar 2014 07.54.36 skrev Thiago Macieira:
> Em qua 19 fev 2014, às 15:19:08, Frederik Gladhorn escreveu:
> > 5. See Ossi's mail. It didn't work. Merging in branches in two directions
> > with  the amount of changes we have is just not very practical. We work
> > around the problem with locking branches and doing fast forward merges
> > from
> > dev->stable for example, but this is a huge issue and would be improved by
> > the branching system suggested. This is a real problem for the release
> > team
> > and whoever else gets involved. The good thing is that this is mostly
> > people working at Digia and does not effect people contributing on their
> > spare time. I could still imagine spending our (my) time in a more
> > productive way.
> 
> Which is also part of the issue: no one outside of Digia knows how difficult
> this is, so no one can offer suggestions on improving the workflow or knows
> what to do or not do to keep the pain level low.
> 
> I'm guessing that the problem is merging two branches together and having
> that result pass the CI, then storing the result in one of the two
> branches. The case right now is that we want to feature-freeze, so we want
> stable to contain 5.3. So I'd guess this is done by checking out stable,
> merging dev, pushing to Gerrit and passing the CI. What is the problem with
> that?

The big difference is that with Ossi's proposal the branching is just that - 
branching off which is atomic - ie creating a new branch off of master/dev.

What we currently have takes time and nerves and a lot of interdependencies 
between the modules. It is not uncommon that qtbase depends on declarative or 
the other way around. Sometimes both ways in which case the revers deps need 
to be disabled in order to get a merge through CI. That and sudden merge 
conflicts that manage to pop up in the right moment. It's not critical, we've 
dealt OK with it for a year now, but it does delay us.

That is what I really like about the proposal - it means only forward merges 
and real branching.

Greetings,
Frederik


> 
> The CI might fail spuriously. Well, we know that and it's a different issue.
> 
> The CI might fail legitimately due to uncaught conflicts. This would have
> happened anyway, regardless of how what the branches are named. The only
> difference might be *when* it happened: if we weren't forced to merge, we
> might skip merging for some time, thus making an N+1 release without all
> the fixes from N.
> 
> The CI might fail in module X because of a change in a dependent module Y.
> 
> In fact, why isn't anybody suggesting we de-modularise? The problem seems to
> be passing the CI in all modules, not with the branches. Despite my
> efforts, we continue to refer people to the monolithic release. And our
> modules use private API of one another, thus making split rebuilds almost
> useless.

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