[Development] Proposal: New branch model

Ville Voutilainen ville.voutilainen at gmail.com
Thu Jan 24 22:29:13 CET 2019


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.



More information about the Development mailing list