[Development] QtCS2019 Notes from "Branch Policy" discussion

[Oswald Buddenhagen]

On Thu, Nov 21, 2019 at 08:50:10AM +0000, Volker Hilsheimer wrote:
>== Discussed and Agreed Proposal ==
>
>We start with Qt 5.15/14/12 (ie 5.15 is “dev” in the Qt 5 series), and 
>continue to merge 5.15 into dev until 5.15 has reached feature freeze.
>
this has NOT been agreed upon. what actually happened is that lars 
interrupted me, summarily dismissed my concerns (thereby implicitly 
rejecting the previous conclusion about mixing merges and cherry-picks), 
and didn't provide as much as a rationale for this other than a vague 
assertion that this would be somehow easier.

>=== Exceptions ===
>
>* Changes file updates are done in the relevant release branch; the files are then carried forward to dev, and cherry-picked down from there as usual
>
the second part actually makes no sense, because it makes tracking the 
original sha1 even harder. it's better to pick from a single point (at 
least logically, that is, what sha1 the pick source footer names; in 
reality, forward-picking picks might be easier due to avoiding repeated 
conflict resolution, but that has been explicitly rejected as a 
"front-end process" (by the same people!) because it slows down the 
integration process).

>* In exceptional cases, and to unblock a release, changes might go first into a release branch and cherry-picked forward into dev
>
there are whole talks from heavyweights like google how that is a silly 
idea, but i suppose it can still work on the precondition that the 
tooling _reliably_ forward-picks everything applicable, even if both the 
owner and their reviewers failed to notice the omission.
and no, considering missing picks acceptable "because it will eventually 
get fixed anyway" is not a position to be taken seriously.

>** another exception is fixes in stable branches that are not relevant for dev
>
yes, that should require an explicit tag, say "Pick-to: none" (the 
footer suggested in the discussion was "Targets:", but i find that 
overly generic and potentially confusing (it seems to ask for the 
current branch as well, but that obviously makes no sense)).

>== Concerns ==
>
>* another commit footer that introduces clutter
>
this could be actually eliminated at the time gerrit cherry-picks the 
change. of course, it's additional effort to implement ...

>=== Tooling ===
>
>* automation triggered by commit message footer
>
it was strongly suggested by alex that having the automation already in 
place should be a hard precondition for changing the process, and i 
agree.