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 _______________________________________________ Releasing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/releasing
