[Development] Notes on "Managing Qt's branches" session @ QCS 2016

[Lars Knoll]

On 08/09/16 17:13, "Development on behalf of Thiago Macieira" <development-bounces+lars.knoll=qt.io at qt-project.org on behalf of thiago.macieira at intel.com> wrote:

>On quinta-feira, 8 de setembro de 2016 07:37:28 PDT Liang Qi wrote:
>> Is it better to have 5.7.2 around 5.8.0 final release and close 5.7 after
>> that? 5.7.1 is very soon in a few weeks. There will be a few months gap
>> between 5.7.1 and 5.8.0/5.8.1. The first release of new branch, like 5.8.0,
>> sometimes it's not tested enough in user(or application developers) side,
>> so some regressions or a bit critical issues will be found between 5.8.0
>> and 5.8.1. It's good for users to have a more stable release of 5.7.2.
>> 
>> If we stick to do release like this kind of order, 5.6.2->5.7.1->5.8.0
>> Beta, it's not very difficult to have a 5.6.3->5.7.2->5.8.0 or similar.
>> 
>> And I would like to see it becomes a convention for future releases.
>
>It wouldn't be bad, if the release team and merging team can make it work. Our 
>concern was that you and Eddy are spending far too much time on doing merges.

It’s basically a question about how we can deal most efficiently with the branches we have. And both merging and cherry-picking are valid ways to work with those branches.

If the branches are closely related, merging is obviously the better choice, as conflicts will be rare. But once branches start diverging more, merging will at some point start to create more overhead (and risk) than cherry-picking back into the older branch.

There are several reasons, why I think we at some point should stop merging from 5.6 to newer branches. 

We are doing significant changes all through our code base currently. C++11 and configuration system related changes are just one example. This will lead to more and more merge conflicts as time goes by. I’ve already reviewed a few merges where it took significant effort to verify that the merge was correct. Merges are done by one person, and that person often doesn’t know all the details of what the patch causing a conflict is trying to achieve. This actually increases our risk of introducing regressions into our newer branches.

Having a lot of branches also increases the complexity for all of us into figuring out where a change should go. In many cases it also does significantly increase turn-around time if a patch is needed in a newer branch. Having a long merge patch from 5.6 to dev can cause delays for all of us. If those delays get too long, this is costly for all of us and will slow us down when developing new features.

A cherry-picking approach for the LTS branch can make sense, as it distributes the burden of bringing the bug fix to both the stable and LTS branch over all developers and doesn’t put it on the one person having to do the merges. It will also help limiting changes in the LTS branch to the things that should really go there.

Cheers,
Lars