[Development] Proposal: New branch model

Simon Hausmann Simon.Hausmann at qt.io
Fri Jan 25 10:50:43 CET 2019


The first attempt at getting a change in is distributed over multiple branches. The staging of the cherry-pick can happen in batches and controlled intervals as with merges.



Simon

________________________________
From: Kari Oikarinen
Sent: Friday, January 25, 2019 10:41:21 AM
To: Simon Hausmann; Lars Knoll; Ville Voutilainen
Cc: Qt development mailing list
Subject: Re: [Development] Proposal: New branch model

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
---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190125/401aeaca/attachment.html>


More information about the Development mailing list