[Releasing] rethinking the branching scheme

Thiago Macieira thiago.macieira at intel.com
Wed Feb 19 16:54:36 CET 2014

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 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.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

More information about the Releasing mailing list