[Development] Proposal: New branch model

[Lars Knoll]

> On 24 Jan 2019, at 22:29, Ville Voutilainen <ville.voutilainen at gmail.com> wrote:
> 
> 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.

After some more thinking, I tend to agree. Qt6 is somewhat special and maybe needs to be treated differently.

But except for Qt 6 I like the proposed policy for a couple of reasons:

* I think it makes the life of casual/new contributors easier. Simply always develop and push against the development branch. The more experienced reviewer can then easily decide that the fix should be cherry-picked into a stable branch.
* The system should be able to handle most of the cherry-picks automatically
* In case something goes wrong, it’s up to the developer/reviewer/maintainer to fix the cherry-pick and get it into the old branch. This leaves conflict resolution with the people that have the knowledge about that part of the code, not one central person that has to babysit merges
* It will somewhat naturally limit fixes going into the stable branches to bug fixes. In most cases, we do not want long patch series in stable branches, as we shouldn’t have feature development there.

A possible solution for Qt 6 could be to treat it as a feature branch from dev, and keep merging from dev, at least as long as possible. Once it’s not possible anymore, we should probably make Qt 6 the new development branch and move all Qt 5 related branches into a stable mode where we only focus on bug fixes. 

Let’s also not forget that Qt 6 is to some extent a temporary problem that we’ll have for maximum one year. After that all of Qt 5 is in stable mode with bug fixing only. Then we can basically go back to a slightly modified cherry-pick mode: Push to dev (Qt6) and cherry-pick into Qt 5.15 for bug fixes. If the code base has diverged and the fix needs to go into Qt 5, we might end up doing two changes, one for Qt6 and one for Qt5. That’s not very different from the situation we had with Qt 4 some years ago.

Cheers,
Lars

> 
> 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.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development