<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi,<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 21 Nov 2019, at 13:52, Oswald Buddenhagen <<a href="mailto:oswald.buddenhagen@gmx.de" class="">oswald.buddenhagen@gmx.de</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">On Thu, Nov 21, 2019 at 08:50:10AM +0000, Volker Hilsheimer wrote:<br class="">
<blockquote type="cite" class="">== Discussed and Agreed Proposal ==<br class="">
<br class="">
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.<br class="">
<br class="">
</blockquote>
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.<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div><br class="">
</div>
<div>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”?</div>
<div><br class="">
</div>
<div>The rationale for the above was (IIRC):</div>
<div><br class="">
</div>
<div>* Merging 5.15 into dev is status quo anyway</div>
<div>* 5.12 is cherry-pick already; 5.13 is frozen</div>
<div>* 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)</div>
<div><br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<div><br class="">
</div>
<div>
<blockquote type="cite" class="">
<blockquote type="cite" class="">=== Tooling ===<br class="">
<br class="">
* automation triggered by commit message footer<br class="">
<br class="">
</blockquote>
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.<br class="">
</blockquote>
</div>
<div><br class="">
</div>
<div><br class="">
</div>
<div>I’ve written down the flow that we’d need to implement here:</div>
<div><br class="">
</div>
<div><a href="https://bugreports.qt.io/browse/QTQAINFRA-3382" class="">https://bugreports.qt.io/browse/QTQAINFRA-3382</a></div>
<br class="">
<div>Let’s start with agreeing on the spec.</div>
<div><br class="">
</div>
<div><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div class="">
<blockquote type="cite" class="">=== Exceptions ===<br class="">
<br class="">
* 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<br class="">
<br class="">
</blockquote>
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).<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div><br class="">
</div>
<div>If I understood and remember the discussion, then the proposed flow would be:</div>
<div><br class="">
</div>
<div>* we make changes to e.g changes-5.12.7 in the 5.12 branch</div>
<div>* once 5.12.7 is released, release team copies the file into dev, and makes a separate commit</div>
<div>* that commit gets cherry-picked from dev down into 5.15 and 5.14 using the standard process</div>
<div><br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<div>If I understand your proposal, the process would be:</div>
<div><br class="">
</div>
<div>* 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)</div>
<div>* we cherry-pick each commit from there forward through 5.14, 5.15, dev</div>
<div><br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<div>So I understand you correctly?</div>
<div><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">
<blockquote type="cite" class="">* In exceptional cases, and to unblock a release, changes might go first into a release branch and cherry-picked forward into dev<br class="">
<br class="">
</blockquote>
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.<br class="">
and no, considering missing picks acceptable "because it will eventually get fixed anyway" is not a position to be taken seriously.<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div><br class="">
</div>
<div>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”.</div>
<div><br class="">
</div>
<div>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].</div>
<div><br class="">
</div>
<div>[1] <a href="http://sidneydekker.com/wp-content/uploads/2013/01/Huberal_2009_Learning-from-organizational-incidents-resilience-engineering-for-high-risk-process-environments.pdf" class="">http://sidneydekker.com/wp-content/uploads/2013/01/Huberal_2009_Learning-from-organizational-incidents-resilience-engineering-for-high-risk-process-environments.pdf</a></div>
<div>[2] <a href="https://www.infoq.com/news/2019/04/allspaw-resilience-engineering/" class="">https://www.infoq.com/news/2019/04/allspaw-resilience-engineering/</a></div>
<div><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">
<blockquote type="cite" class="">** another exception is fixes in stable branches that are not relevant for dev<br class="">
<br class="">
</blockquote>
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)).<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div><br class="">
</div>
<div>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 :)</div>
<div><br class="">
</div>
<div>Anyway, I offered some alternatives in the JIRA ticket, we can do the bikeshedding there.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">
<blockquote type="cite" class="">== Concerns ==<br class="">
<br class="">
* another commit footer that introduces clutter<br class="">
<br class="">
</blockquote>
this could be actually eliminated at the time gerrit cherry-picks the change. of course, it's additional effort to implement …</div>
</div>
</blockquote>
</div>
<div class=""><br class="">
</div>
<br class="">
<div class="">True; seems to me like a “nice to have” thing that we can add once the basics are in place.</div>
<div class=""><br class="">
</div>
<div class="">Volker</div>
<div class=""><br class="">
</div>
</body>
</html>