[Development] Proposal: New branch model

[Simon Hausmann]

It's a fair point to raise.


The closest scenario that I can think of that we've had in the past with a long living branch was 5.6 before it entered cherry-picking mode. The first change to qtbase 5.6 was uploaded to Gerrit on August 11th 2015. The last merge that I can see away from 5.6 was on November 25th 2016. That's ~16 months of merging.


Short of other options, I think the method of using git merge is the option that's least painful for a long lived qt 6 branch.


Simon

________________________________
From: Ville Voutilainen <ville.voutilainen at gmail.com>
Sent: Thursday, January 24, 2019 10:29:13 PM
To: Simon Hausmann
Cc: Jedrzej Nowacki; development at qt-project.org
Subject: Re: [Development] Proposal: New branch model

On Thu, 24 Jan 2019 at 20:26, Simon Hausmann <Simon.Hausmann at qt.io> wrote:
>
>
> I would see the biggest long term impact with the massive amount of cherry picks from dev to qt6 over a long period of time.
>
> Git rerere works locally, so it doesn’t help in this setup I think.

Completely seriously, without any preference to either branching
approach: aren't we going to be in some sort of trouble
with the qt6 branch anyway, no matter what we do? Following on a bit:

Pardon me if I missed some important part of the motivation of all of
this, but I *CAN'T* see how this should, could,
or needs to be an approach that helps with the qt6 branch
merge/cherry-pick/rebase. I don't think that's going to
be a pleasant operation whatever we do.

I would like a "push to trunk, backport to release-branches" approach
going forward. As in, once we have the usual
umpteen X.y branches, it's a simple approach.

But I don't see how going from merge-forward (except also
merge-backward sometimes) to cherry-pick-backward
(except also cherry-pick forward, or kinda sideways to qt6, and maybe
sometimes merge in some direction) is going
to help us with qt6. These matters seem orthogonal.

Qt6 and dev are going to diverge. Drastically, eventually. I don't
know how to solve that. A new branching policy
is not going to help with that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190125/2aed23bf/attachment.html>