[Development] Proposal: New branch model

Fri Jan 25 11:07:33 CET 2019

First the change would need to land in the targeted branch, then the 
cherry-picks to other branches.

Batching and controlled intervals are possible, but taken to an extreme they
would replicate the current load as a group of commits would be taken in a
single build as with merges currently. If there's less batching, there are more
integrations and thus more load. Could be only a little more, of course.

A lot of the stated advantages have also been about how creators of the changes
can take ownership of them and how changes can proceed into other branches
indepently. If you are can (and are responsible for) staging the cherry-picks if
the initial stage is not successful, how would you ensure the batching?

Sometimes there are conflicts in the cherry-picks. Will other changes in the
same batch wait for them to be fixed? Or is the batching smart enough to
understand whether there is a dependency or not?

I think there is a risk of reinventing the merges here. Or if not reinvention,
at least creating a new tool that is going to see feature creep like Sergio's
mail hinted from experience.

-- 
Kari

On 25.1.2019 11.50, Simon Hausmann wrote:
> 
> 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
> ---

-- 
---
Kari Oikarinen
Senior Software Engineer

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