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.
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
