[Development] Proposal: New branch model

[Kari Oikarinen]

How would the CI load not change? Rather than one merge bringing multiple
commits, each change would still be picked individually.

I also think the cherry-picking model makes more sense when branches with less
action get the cherry-picks. The cherry-picking conflict issues grow as the
amount of changes grow.

If we want more cherry-picking, I think we should rather pick the most frozen
branches not yet in cherry-picking to convert. That of course would only help
with (1).

-- 
Kari

On 25.1.2019 11.10, Simon Hausmann wrote:
> 
> I think it's worthwhile to develop the tooling to automate cherry-picking. That 
> tooling is something that is perhaps best tried on a release branch first.
> 
> 
> I do quite like what Allan suggested: We could try the cherry-pick the other way 
> around. Volker, Lars, Thiago etc. surely remember the p4i script we used to have 
> when we were using Perforce. Imagine that with more automation.
> 
> 
> (1) Liang's work load gets reduced dramatically - conflict resolution is 
> distributed.
> 
> (2) Changes hit the customer relevant branch ASAP.
> 
> (3) The load on the CI does not change for anybody working in dev.
> 
> 
> 
> 
> Simon
> 
> --------------------------------------------------------------------------------
> *From:* Lars Knoll
> *Sent:* Friday, January 25, 2019 9:05:45 AM
> *To:* Ville Voutilainen
> *Cc:* Simon Hausmann; Qt development mailing list
> *Subject:* Re: [Development] Proposal: New branch model
>> 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
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
> 

-- 
---
Kari Oikarinen
Senior Software Engineer

The Qt Company
Elektroniikkatie 13
90590, Oulu, Finland
kari.oikarinen at qt.io
+358 50 5281010
http://qt.io
---