[Development] QtCS2019 Notes from "Branch Policy" discussion

[Volker Hilsheimer]

Hi,

On 21 Nov 2019, at 13:52, Oswald Buddenhagen <oswald.buddenhagen at gmx.de<mailto:oswald.buddenhagen at gmx.de>> wrote:

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.


Since nobody contradicts your objection, I’m happy to correct the minutes from the discussion with something else, 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”?

The rationale for the above was (IIRC):

* Merging 5.15 into dev is status quo anyway
* 5.12 is cherry-pick already; 5.13 is frozen
* Switching 5.14 into cherry-picking mode is not a significant change to existing way of working; it’s just making the change earlier (or at all, when 5.14 typically would just become frozen around the time 5.15.0 is released)

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.


=== 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.


I’ve written down the flow that we’d need to implement here:

https://bugreports.qt.io/browse/QTQAINFRA-3382

Let’s start with agreeing on the spec.


=== 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).


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.

So I understand you correctly?


* 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.


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. See Sidney Dekker [1] or John Allspaw [2].

[1] http://sidneydekker.com/wp-content/uploads/2013/01/Huberal_2009_Learning-from-organizational-incidents-resilience-engineering-for-high-risk-process-environments.pdf
[2] https://www.infoq.com/news/2019/04/allspaw-resilience-engineering/


** 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)).


Agree; naming stuff is hard, but better to have something that’s clear and explicit. It would be in the commit template anyway, so “hard to type” won’t be an argument :)

Anyway, I offered some alternatives in the JIRA ticket, we can do the bikeshedding there.

== 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 …


True; seems to me like a “nice to have” thing that we can add once the basics are in place.

Volker

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20191126/7c10a149/attachment-0001.html>