[Development] QtCS2019 Notes from "Branch Policy" discussion

[Volker Hilsheimer]

> On 6 Dec 2019, at 14:45, Filippo Cucchetto <filippocucchetto at gmail.com> wrote:
>> Il giorno ven 6 dic 2019 alle ore 11:18 Volker Hilsheimer <volker.hilsheimer at qt.io> ha scritto:
>> > * Fresh commits are normally only allowed on dev, with an exception for
>> >  changes files and last-minute hot-fixes on release branches.
>> > * Every commit has a Pick-to: footer (or whatever name we chose)
>> >  that lists where it's to be cherry-picked to.
>> > * When a commit merges and isn't itself a cherry-pick, it gets
>> >  cherry-picked to every branch named on its footer.
>> > 
>> > Then we don't handle forward-picks any differently than backward-picks,
>> > aside from only allowing the former in rare cases; and we don't handle
>> > hot-fixes any differently than change files.  Simple rules are easy to follow.
>> > 
>> >       Eddy.
>> 
>> 
>> Updating the JIRA ticket with this concise summary from Eddy, we can start implementing the tooling support based on this flow.
>> 
>> How we roll this out (phased rollout to avoid “big bang”, or “all in” to have a homogenous workflow) we can decide when we get there.
>> 
>> Cheers,
>> Volker
> 
> 
> I'm just a follower of this thread and i don't pretend to having understood everything but i dont' really get how having backward commits from dev to previous release branch could be handled from a dev point of view. 


One answer given at the CS discussion was: “like in (practically) any other software project out there”.


> How can you automatically backport a simple fix that is using a particular C++ standard feature allowed on dev and not on previous branches?


Either write the fix so that it works in the branches you want the fix to be in; or accept that the bug will only be fixed in a future release made off of dev; or backport manually.

Whether any of the former options is acceptablel, or whether the latter option is worth it, is a decision you can make. Or The Qt Company can make when a customer asks for your contribution into dev to be backported to an LTS release.

FWIW, this is no different than what we have today. Making a fix in 5.14, you have to cherry-pick it to 5.12, where the code the patch needs to be made in might be significantly different. And forward merges have the same problem  (both in theory and in practice), just that you don’t have a choice.

> With forward merges this causes dev to have an "old" standard but still feasible.
> Same for a fix that depends on changes on dev not cherry picked to previous branches. 
> With forward merges when you commit on a "old" branch you suppose that the forward merges
> will just succeed given that your parent commits should be also on forward branches. 


Sounds nice, but the reality is that this has not been the case. Forward-merging hasn't worked without a fair bit of hand-holding; one big difference is that forward-merging is a centralized process, so the hand-holidng had to be done by the merge master who has nothing to do with either the code that’s being modified, or the patch that caused conflicts. And nobody wants to be the merge-master.


Also (as people confirmed during the discussion at CS) the forward merging process causes significant delays. Fixing a bug in 5.15 that you would like to modify to use modern C++, or refactor whatever smelly code you might have run into, in dev means that you spend weeks on a simple bug fix; merging it into 5.15; waiting for forward merging (and potentially integrations) to succeed; adjusting the merged change in dev; merging into dev.

This kills the motivation to do necessary refacorings and structural code improvements, which is not good for the project.


Cheers,
Volker