[Releasing] rethinking the branching scheme
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
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