[Development] QtCS2019 Notes from "Branch Policy" discussion

[Oswald Buddenhagen]

On Tue, Nov 26, 2019 at 02:42:46PM +0000, Volker Hilsheimer wrote:
>but I’d need a practical proposal to replace it with. Do I understand 
>correctly that you’d rather go “all in”, i.e once we are ready, flip 
>all branches to “cherry-pick only”?
>
all-in is one option, yes.
it has the advantage that it is easy to grasp.
also, soft-branching would be instantly a thing of the past then.

the second option is to add yet another "forward merging domain" for 
6.x, so from the current set of 5.9/5.9.x, 5.12/5.12.x, and 
dev/5.15/5.14/5.14.x, the latter would be split into dev (later, 
6.x/6.x.y are added here) and 5.15/5.14/5.14.x. i.e., only 6.x gets 
"detached", to shorten the pipeline and get out of merging hell. this 
isn't anything new - it's essentially how we handled qt4 after qt5 was 
branched off, except that back then there was no alternative due to the 
repo split.
this has the obvious downside that the mental model is more complicated, 
but not a lot more than before, and the sanity bot already points out 
failures to follow the process, semi-reliably (it could do even better).

a notable observation is that neither approach needs a transitional 
phase where both merging and cherry-picking are done between the same 
branches.

>So, starting with the new process within the Qt 5.x family of branches 
>gives us a phased approach with multiple, smaller, accumulating changes 
>rather than the “big bang” that several heavyweights at Google would 
>have an opinion about.
>
i have no clue what you're saying here.

>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
>
that is correct.

>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.
>
i have no clue what you mean by "a different history". only the times 
when the cherry-picks hit their respective targets change.

>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)
>
huh? you want to pick both forward and backward? that's insane.

>* 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.
>
no, it isn't. in fact, it's just the new standard process, where 
back-picks are footer-induced, while forward-picks are automated and 
footer-suppressed. jumping directly to dev otoh would require a) 
suppressing the auto-forward-picking and b) additional action to trigger 
the back-picking in turn.

>I do agree with you and those other heavyweights; we should focus on 
>making the correct process work efficiently and reliably enough to not 
>require “hotfix shortcuts”.
>
>However, those same heavyweights agree that complex systems don’t 
>become resilient by design, but by the ability of their human operators 
>to deal with exceptional situations.
>
you're misapplying the findings. they are talking about dealing with the 
truly unexpected, not about something as predictable as needing to apply 
hotfixes to a release branch.

p.s.: please stop using outlook web access when interacting with 
technical people. the regular outlook client is capable of producing 
proper plain-text quoting.