[Development] QtCS2019 Notes from "Branch Policy" discussion

[Volker Hilsheimer]

> On 27 Nov 2019, at 11:57, Edward Welbourne <edward.welbourne at qt.io> wrote:
> 
> Volker Hilsheimer (26 November 2019 15:42) wrote:
> [snip]
>> If I understood and remember the discussion, then the proposed flow
>> would be:
>> 
>> * we make changes to e.g changes-5.12.7 in the 5.12 branch
>> * once 5.12.7 is released, release team copies the file into dev, and
>>  makes a separate commit
>> * that commit gets cherry-picked from dev down into 5.15 and 5.14
>>  using the standard process
>> 
>> The rationale is that we have only a single such "forward-porting"
>> commit for each release, and to the largest extend follow the standard
>> process. The disadvantage is that the changes-5.12.7 file in dev will
>> have a different history than the same file in 5.12.
>> 
>> If I understand your proposal, the process would be:
>> * changes files are updated directly in the release branch, e.g. 5.12
>>  (assuming that 5.12.7 is only for the release team anyway)
>> * we cherry-pick each commit from there forward through 5.14, 5.15, dev
>> 
>> The advantage here is that we can track each commit, and have the same
>> history for those files. The disadvantage is that it’s a bigger
>> departure from standard process, with more room for error and
>> overhead.
> 
> Alternative proposal (possibly just a restatement):
> * 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