[Development] QtCS2019 Notes from "Branch Policy" discussion
oswald.buddenhagen at gmx.de
Wed Nov 27 10:50:42 CET 2019
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
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
>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
>* 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.
More information about the Development