[Development] QtCS2019 Notes from "Branch Policy" discussion

[Filippo Cucchetto]

I'm just a follower of this thread and i don't pretend to having understood
everything but i dont' really get how having backward commits from dev to
previous release branch could be handled from a dev point of view.
How can you automatically backport a simple fix that is using a particular
C++ standard feature allowed on dev and not on previous branches?
With forward merges this causes dev to have an "old" standard but still
feasible.
Same for a fix that depends on changes on dev not cherry picked to previous
branches.
With forward merges when you commit on a "old" branch you suppose that the
forward merges
will just succeed given that your parent commits should be also on forward
branches.

F.

Il giorno ven 6 dic 2019 alle ore 11:18 Volker Hilsheimer <
volker.hilsheimer at qt.io> ha scritto:

> > On 27 Nov 2019, at 11:57, Edward Welbourne <edward.welbourne at qt.io>
> wrote:
> >
> > Volker Hilsheimer (26 November 2019 15:42) wrote:
> > [snip]
> >> 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.
> >
> > Alternative proposal (possibly just a restatement):
> > * Fresh commits are normally only allowed on dev, with an exception for
> >  changes files and last-minute hot-fixes on release branches.
> > * Every commit has a Pick-to: footer (or whatever name we chose)
> >  that lists where it's to be cherry-picked to.
> > * When a commit merges and isn't itself a cherry-pick, it gets
> >  cherry-picked to every branch named on its footer.
> >
> > Then we don't handle forward-picks any differently than backward-picks,
> > aside from only allowing the former in rare cases; and we don't handle
> > hot-fixes any differently than change files.  Simple rules are easy to
> follow.
> >
> >       Eddy.
>
>
>
> Updating the JIRA ticket with this concise summary from Eddy, we can start
> implementing the tooling support based on this flow.
>
> How we roll this out (phased rollout to avoid “big bang”, or “all in” to
> have a homogenous workflow) we can decide when we get there.
>
> Cheers,
> Volker
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>


-- 
Filippo Cucchetto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20191206/54d49acd/attachment.html>