[Development] Proposal: New branch model

[Robert Loehning]

Am 25.01.2019 um 11:08 schrieb Lars Knoll:
> 
> 
> On 25 Jan 2019, at 10:10, Simon Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>> 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.
> 
> The risk with this is that we might end up having fixes in a stable branch that don’t make it do dev for various reasons, so it’ll regress in the next minor release.
> 
> 
> (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.
> 
> The CI problem comes from the fact that if we have a high rate of stages to qtbase/dev, we at some point get into a deadlock situation, even if we disregard any flakiness in the system. That’s because higher rates imply that more changes are tested together. This in turn increasing the risk of rejection of all changes because of one bad change in the set. So the current system doesn’t scale and basically rate limits the amount of changes going into a branch (or worse, we end up getting traffic jams where the actual rate actually goes down to zero).
> 
> To me this means we need to seriously rethink that part of our CI system, and ideally test changes (or patch series) individually and in parallel. So maybe we should adjust our CI system that way:
> 
> * test changes (or patch series) individually
> * If they pass CI merge or cherry-pick them into the branch
> * reject only if the merge/cherry-pick gives conflicts
> 
> This adds a very small risk that two parallel changes don’t conflict during the merge/cherry-pick process, but cause a test regression together. To help with that, we can simply run a regular status check on the repo. If this happens the repo will be blocked for further testing until someone submits a fix or reverts an offending change, which is acceptable.

Could that be solved by testing the combinations of changes again?

* test changes (or patch series) individually
* If they pass CI merge or cherry-pick them into some local branch
* reject if the merge/cherry-pick gives conflicts
* when time period x has passed or the local branch contains y changes, 
test the local branch
   good: push the local branch to the public one
   bad:  repeat step four with a subset of the changes it had before

Assuming that y is significantly greater than 1, the added overhead for 
one more test run seems relatively small to me.

Cheers,
Robert

> 
> Another advantage is that this would pave the road towards a system where CI testing happens before human review, so we can in the longer term avoid duplicated review/approval work.
> 
> Cheers,
> Lars
> 
> 
> 
> 
> 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<mailto:ville.voutilainen at gmail.com>> wrote:
>>
>> On Thu, 24 Jan 2019 at 20:26, Simon Hausmann <Simon.Hausmann at qt.io<mailto: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.