Re: [Development] Proposal: New branch model

[Lars Knoll]

Lots of good discussions around the proposal from Jedrzej. It seems like this 
has been inconclusive for the moment. Both cherry-picking and the current model 
have it’s advantages and disadvantages. One major concern was that we’d 
overload especially qtbase/dev integrations and this would lead to a complete 
block in qtbase, As this is a concern already today (it’s really way too 
difficult to get a change into qtbase), I’d propose that we now first get two 
other things in place before we consider changes to how we do things here.

The first change is to implement the new module handling (see the ‘Qt modules’ 
thread).

Secondly, we need to change our CI to be able to handle multiple CI runs in 
parallel for a single repository/branch. This change is something I believe is 
required in any case (independent of the branching model to make it easier to 
land changes).

That change implies that we can have multiple staging branches that are tested 
in parallel instead of limiting ourselves to one. If a branch passes it’ll get 
merged into the target branch (unless there are conflicts). With this approach, 
we are running a minimal risk that two staging branches that are tested 
independently are not conflicting code wise, but will together cause an auto 
test regression somewhere. If that happens, we’ll find out very quickly in any 
case (because the branch will be blocked for further integrations until this is 
fixed), so I don’t think this is problematic.

There’s also a good chance that a good part of the problems we’re having with 
merges will go away once we have these two things implemented. So I’d say let’s 
do those first, see how it goes and then reconsider our branching/merging 
strategy.

Cheers,
Lars

On 10 Feb 2019, at 21:31, Lisandro Damián Nicanor Pérez Meyer 
mailto:perezme...@gmail.com>> wrote:

El dom., 10 feb. 2019 05:44, Sune Vuorela 
mailto:nos...@vuorela.dk>> escribió:


[snip]

I'm mostly a casual contributor, mostly dealing with fixes to bugs found
in specific releases. I'm doing my fixes in those releases. Because
that's where I need them. If I could just then push it and more or less
forget about it, that's the thing that would make it easier.

This seems to me that I need to move the fix forward to dev, then push
it, then backport it. I might not even have a dev build handy. Because
I'm basing my work on top of something released.

+1. This is the normal case for distributors (distros) and the patches we 
normally work on.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Lisandro Damián Nicanor Pérez Meyer]

El dom., 10 feb. 2019 05:44, Sune Vuorela  escribió:


[snip]

I'm mostly a casual contributor, mostly dealing with fixes to bugs found
> in specific releases. I'm doing my fixes in those releases. Because
> that's where I need them. If I could just then push it and more or less
> forget about it, that's the thing that would make it easier.
>
> This seems to me that I need to move the fix forward to dev, then push
> it, then backport it. I might not even have a dev build handy. Because
> I'm basing my work on top of something released.


+1. This is the normal case for distributors (distros) and the patches we
normally work on.

>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Sune Vuorela]

On 2019-01-25, Lars Knoll  wrote:
> * 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.

I'm mostly a casual contributor, mostly dealing with fixes to bugs found
in specific releases. I'm doing my fixes in those releases. Because
that's where I need them. If I could just then push it and more or less
forget about it, that's the thing that would make it easier.

This seems to me that I need to move the fix forward to dev, then push
it, then backport it. I might not even have a dev build handy. Because
I'm basing my work on top of something released.

/Sune
 - independent contractor, KDE Developer and Debian Developer

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Frederik Gladhorn]

On fredag 25. januar 2019 21:40:07 CET Thiago Macieira wrote:
> On Friday, 25 January 2019 01:10:35 PST Simon Hausmann wrote:
> > 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.
> 
> I vaguely remember it. But your bringing it up is *not* an argument in
> favour of cherry-picking. Doing backporting properly in the Perforce days
> was a nightmare. We did not consistently backport fixes to earlier
> releases, even when we had a somewhat long stable series (4.3 went through
> 4.3.5).
> 
> Also, unlike Git, Perforce "merges" *were* a series of cherry-picks and it
> did know which commits had been cherry-picked and which ones hadn't. So if
> you told it to merge a range, it would tell you everything that was
> missing. More importantly, the range did not have to be contiguous, so you
> could cherry-pick only your own changes and let others deal with theirs. It
> also helped p4 had a pretty good automated conflict resolution in the
> command-line (today, I use kdiff3 for that, via git mergetool).

There is "git cherry" which tries to determine if something has been cherry-
picked between branches. But it's clearly not the most widely known, nor one 
of the best tools in the git offering. I have to look up up the order of 
source and destination arguments every time I run it... and then I still get 
it wrong. And indeed, the information that a cherry-pick happened is not 
properly recorded (which is why git cherry-pick -x is pretty much a must).

https://git-scm.com/docs/git-cherry

Cheers,
Frederik



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Sergio Ahumada]

On 28.01.19 14:37, Jedrzej Nowacki wrote:
>>
>> disadvantages:
>> - most developers don't know how to handle the propagation failures
>> -- I already moved on and am working on something else, do you want me
>> to switch to '5.19' to fix a change I did in '5.12' ? oh, and it failed
>> in '5.18' as well? why don't you do merges instead and leave alone?
>> [true story :-)]
>> - change can pass the CI and found to be problematic later on
>> -- oh, I need to fix my change in 5 branches now? [Gerrit 2.14 has a
>> cherry-pick button in the UI now, so this is not a problem with that
>> version]
>> - automated cherry-pick process/bot/script has to be maintained
>> -- one change not merged might lead to lots of changes to fail with
>> merge conflicts, staying open in gerrit forever
>> -- hey, can you add intelligence to the bot so it know how to merge the
>> open changes once the dependency is merged?
>> -- hey, can you add intelligence to the bot so it can cherry-pick them
>> in the right order?)
>> - yes, git-cherry-pick does weird things. I have seen it cherry-picking
>> the same change twice without problems (same line twice in the file, I
>> think I was an include guard that compiled but behaved weirdly, or similar)
>>
>> my 2€
> 
> Thank you for the story, do I get it correctly that the most of problems are 
> social and global flakiness of the system?
> 
> Cheers,
>   Jędrek

Yes, the system works pretty nice as long as all changes are being
merged .. as soon as one change does not get merged (and it is a
dependency for other changes) then they start to pile up and somebody
has to manually work on them anyways .. usually the Release Manager ..

but as said, it works around 80% of the time without issues (other than
people with different opinions on how it 'would work better for my
particular workflow' and writing customized scripts to keep 'staging'
the change without looking at the failures ...)

-- 
Sergio Ahumada
sahum...@texla.cl


pEpkey.asc
Description: application/pgp-keys
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Thiago Macieira]

On Monday, 28 January 2019 04:54:58 PST Volker Hilsheimer wrote:
> A change making it into dev where it can be noticed and scrutinized by a
> bunch of people that didn’t participate in the merge request, where it can
> pass additional build and configurations, and generally be exposed to
> different cases that are not covered by CI - isn’t that valuable?

Valuable, but how is that different from today? All it takes is that people 
run the stable branch, which they should, so as to give more eyes to the thing 
that needs stability the soonest.

I've been doing that for 7 years.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[André Pönitz]

On Mon, Jan 28, 2019 at 12:54:58PM +, Volker Hilsheimer wrote:
> > Wouldn't we expect those external patchers to submit changes to dev
> > only? Then the module maintainer, or an LTS version maintainer (is
> > there a maintainer for each LTS version?) would decide whether the
> > change should be cherrypicked into an LTS version.
> > 
> > martin
> 
> 
> Indeed; esp in the cases where a causal contribution comes in, and
> where then the maintainers need to invest time to decide whether or
> not this is material for a stable branch, dev should be the first
> branch.
> 
> A change making it into dev where it can be noticed and scrutinized by
> a bunch of people that didn’t participate in the merge request, where
> it can pass additional build and configurations, and generally be
> exposed to different cases that are not covered by CI - isn’t that
> valuable?

I would think so.

Also, in the not-so-uncommon case where there is no really obvious
target branch (e.g. because reviewers disagree on whether it's LTS
material), people who really want to have that change in another branch
for which there was no consensus in the initial review are free to
attempt porting the change to that branch, using mainly their own
resources, which looks like a fair deal to me under these circumstances.

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Edward Welbourne]

Jedrzej Nowacki (Monday, 28 January 2019 3:54 PM)
>> We have the same problem right now, just in the opposite
>> direction. One want to fix version 5.9, why the person should help
>> with merging and solving problems in 5.12? At least the problem would
>> be visible in gerrit as an not staged change.

Mitch Curtis (28 January 2019 16:40)
> Don't changes have to go to 5.12 first and then be backported to 5.9
> with the current model?

Not strictly, as I understand it.  Change needs to land in *some* live
branch, but that could be dev - although it'll usually be stable, since
it makes little sense to cherry-pick back to LTS a change not also worth
making in stable.  Once it's landed, it can be cherry-picked back to any
LTS.  When it is, though, it can be cherry-picked back to several LTS
branches at the same time (just as, in Jedrzej's model, we would do to
all branches other than dev).

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> Jedrzej Nowacki
> Sent: Monday, 28 January 2019 3:54 PM
> To: Robert Loehning 
> Cc: development@qt-project.org
> Subject: Re: [Development] Proposal: New branch model
> 
> On Monday, January 28, 2019 2:38:44 PM CET Robert Loehning wrote:
> > Am 28.01.2019 um 14:09 schrieb Jedrzej Nowacki:
> >
> > > On Friday, January 25, 2019 3:23:36 PM CET Robert Loehning wrote:
> > >
> > >>> Testing whether the bug that I’m fixing exists in dev or not is
> > >>> part of the drill of fixing bug, isn’t it? Why would you spend
> > >>> time on fixing something in 5.12 without checking whether the
> > >>> issue is still present in the latest codebase? Perhaps the issue
> > >>> has been fixed already, just without the author considering it
> > >>> relevant for 5.12 (perhaps for good reasons).
> > >>
> > >> Why would somebody who maintains a project on Qt5 but made the
> > >> decision to not migrate it to Qt6 care about fixing the latter?
> > >>
> > >>
> > >>
> > >> Cheers,
> > >> Robert
> > >
> > >
> > > Project that is not being updated is not maintained. Not maintained
> > > projects
>  should not take part of the mainstream.
> > >
> > > Cheers,
> > >
> > >Jędrek
> > >
> > >
> > >
> >
> >
> > I mean an external project which is based on Qt, like some commercial
> > application. Say they decided - for good or bad reasons - that they
> > will not migrate to Qt 6, but they require a fix in Qt 5. They even
> > provide this fix, but why would they care about making it work in Qt 6?
> >
> > Cheers,
> > Robert
> 
> We have the same problem right now, just in the opposite direction. One
> want to fix version 5.9, why the person should help with merging and solving
> problems in 5.12? At least the problem would be visible in gerrit as an not
> staged change.

Don't changes have to go to 5.12 first and then be backported to 5.9 with the 
current model?
 
> Cheers,
>   Jędrek
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Alex Blasche]

>From: Development  on behalf of Jedrzej 
>Nowacki 

>> I mean an external project which is based on Qt, like some commercial
>> application. Say they decided - for good or bad reasons - that they will
>> not migrate to Qt 6, but they require a fix in Qt 5. They even provide
>> this fix, but why would they care about making it work in Qt 6?

>We have the same problem right now, just in the opposite direction. One want
>to fix version 5.9, why the person should help with merging and solving
>problems in 5.12? At least the problem would be visible in gerrit as an not
>staged change.

The problem is significantly lower because the amount of patches is smaller. 
The 5.9 series accepts less patches due to stricter commit policy, but yes we 
all test such cherry-picks in 5.9, right?

--
Alex
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Monday, January 28, 2019 2:38:44 PM CET Robert Loehning wrote:
> Am 28.01.2019 um 14:09 schrieb Jedrzej Nowacki:
> 
> > On Friday, January 25, 2019 3:23:36 PM CET Robert Loehning wrote:
> > 
> >>> Testing whether the bug that I’m fixing exists in dev or not is part of
> >>> the drill of fixing bug, isn’t it? Why would you spend time on fixing
> >>> something in 5.12 without checking whether the issue is still present
> >>> in
> >>> the latest codebase? Perhaps the issue has been fixed already, just
> >>> without the author considering it relevant for 5.12 (perhaps for good
> >>> reasons).
> >> 
> >> Why would somebody who maintains a project on Qt5 but made the decision
> >> to not migrate it to Qt6 care about fixing the latter?
> >>
> >>
> >>
> >> Cheers,
> >> Robert
> > 
> > 
> > Project that is not being updated is not maintained. Not maintained
> > projects
 should not take part of the mainstream.
> > 
> > Cheers,
> > 
> >Jędrek
> > 
> > 
> > 
> 
> 
> I mean an external project which is based on Qt, like some commercial 
> application. Say they decided - for good or bad reasons - that they will 
> not migrate to Qt 6, but they require a fix in Qt 5. They even provide 
> this fix, but why would they care about making it work in Qt 6?
> 
> Cheers,
> Robert

We have the same problem right now, just in the opposite direction. One want 
to fix version 5.9, why the person should help with merging and solving 
problems in 5.12? At least the problem would be visible in gerrit as an not 
staged change.

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Friday, January 25, 2019 2:17:15 PM CET Edward Welbourne wrote:
> On 25 Jan 2019, at 10:10, Simon Hausmann 
mailto:simon.hausm...@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.
> 
> Lars Knoll (25 January 2019 11:08)
> 
> > 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.
> 
> It should be fairly trivial to ensure we tag the cherry-picks in such a
> way that some routine script can alert relevant folk to ones that
> haven't been sorted out within a month, or before the next release on
> the branch they targeted.  I think this is less of a reason to worry
> than you suppose.
> 

Actually, I share the concern about regressions, if we turn the cherry-pick 
direction. Yes, we can detect such situations, but it is not given that anyone 
would act on it. What if an author is not responding or not doing anything 
about the dev cherry-pick? Who will volunteer to fix the situation? What if, it 
is actually hard task and it can not be done during a release time window?

I really prefer a system that automatically tries to not regress. I believe in 
transparency; maintenance of stable branch is a cost and cherry-pick from dev 
to stable shows the cost.

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Alex Blasche]

>From: Development  on behalf of Edward 
>Welbourne 

Volker Hilsheimer (28 January 2019 13:54) agreed:
>> Indeed; esp in the cases where a causal contribution comes in, and
>> where then the maintainers need to invest time to decide whether or
>> not this is material for a stable branch, dev should be the first
>> branch.

>It (mostly) suits *our* needs best for everything to land in dev; but
>not all potential contributors have the same priorities as us.

Past experience has shown that Eddy is very much correct here. Customers fix in 
their branch. If you have little knowledge of Qt's internals and you ask this 
person to fix it in a branch that is not even the one they use puts up an 
extremely high threshold for contributions. In fact I can recount multiple 
times when a fix was not suitable for LTS and I requested a patch move to dev 
and the response was, no time to test that outside my own use case. . Later 
asking them to also make cherry-picks backwards (in case of conflict), just 
worsens the situation. 

We want more contributions from people who have little time for their own 
project. This suggestion makes  is completely counter productive to people not 
working full time outside of Qt. 

 
>> A change making it into dev where it can be noticed and scrutinized by
>> a bunch of people that didn’t participate in the merge request, where
>> it can pass additional build and configurations, and generally be
>> exposed to different cases that are not covered by CI - isn’t that
>> valuable?

>Yes, that is valuable; so is the stability of stable branches.
>Users surely have stronger expectations of stability for stable branches than
>for cutting-edge first releases of a later minor version.  So breakage
>in dev (caused by things merged up to it) is less harmful than breakage
>in stable (caused by things cherry-picked down to it).
>Which of these valuable things do we prize more highly ?

I value the customer contribution more than a merge effort on my behalf to keep 
the repo going. As I said earlier, Liang's merge effort can be distributed and 
I am happy to to do that for the repo's I maintain. That's how valuable the 
patch from a random contributor in his context is for me. Mind you the 
scrutinization in dev needs to be proven first. I don't buy it when we cannot 
even mange to find enough reviewers for patches.

--
Alex
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Friday, January 25, 2019 9:25:16 AM CET Simon Hausmann wrote:
> I'm somewhat attracted to the proposed model, in conjunction with automation
> and by treating Qt6 differently.
>  
> However Allan's last point is what sticks to me most, the load on the CI and
> the resulting impact on productivity:
> 
> If all it would take to get changes distributed is a cherry-pick, then I can
> totally see how this can fly. However with a blocking CI and the rate of
> flakyness we are experiencing at least in qtbase, I think this carries a
> high risk of slowing down development.

Bigger then the current merging strategy? 

>  (...)
> It would seem that quite a bit of
> tooling needs to be developed first anyway?

Nah the cherry-picking bot would be reasonably easy. Sanity bot has the option 
to warn already built-in, although I haven't looked how to enable it for all 
non dev branches. Migration itself requires some one time scripting and 
backups, I guess it would be rather about logistics and synchronization, then 
technical challenges.

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Thursday, January 24, 2019 10:29:13 PM CET Ville Voutilainen wrote:
> On Thu, 24 Jan 2019 at 20:26, Simon Hausmann  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? 

I agree. There is also feature based approach, which would make code uglier... 
All in all we will pay some price for keeping Qt6 and Qt5 in parallel.

> 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.
> 
> 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.

It will simplify Qt6 mainly by :
 - distribution of conflict resolution
 - Qt6 development will not be delayed by waiting for merges to happen, 
because some refactoring needs to be done in more stable branches (for example 
tests)

I agree, the branching model is not a silver bullet, it will be ugly anyway, 
let's not make it very slow in the same time :-)

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

On 28.1.2019 15.09, Jedrzej Nowacki wrote:
> On Thursday, January 24, 2019 3:18:59 PM CET Kari Oikarinen wrote:
>> On 24.1.2019 16.15, Edward Welbourne wrote:
>>
>>> Kari Oikarinen (24 January 2019 15:02)
>>>
 The rest of the paragraph talks about a situation where we will have two
 stable
>   branches alive at the same time. Typically we don't, because
 once 5.x+1 is created, 5.x is closed.
>>>
>>>
>>> Not quite: once 5.x+1 is *released*, 5.x (if not LTS) is closed
>>> (unless we have a pressing reason to release another 5.x.y).
>>> So, in the interval between 5.x+1 branching and releasing,
>>> we have three branches.
>>
>>
>> Right, so typically we indeed have two stable branches open. Thanks for
>> correcting me.
>>
>>
>>>
>>>
 But 5.12 is an LTS version, so it will still stay open.
>>>
>>>
>>> Indeed.
>>>
>>>
 But at what point (under current process) would be switch it to
 cherry-pick only
>   mode? I don't remember when it happened for 5.9. It
 could be when 5.13 is created and then there would be no release blocked
 by waiting for a merge.>
>>>
>>> We switch to cherry-picking into 5.12 when 5.14 is created.
>>> See QUIP-5,
>>> * https://quips-qt-io.herokuapp.com/quip-0005.html
>>>
>>> So creation of 5.14 switches our merge pattern from 5.12->5.13->dev
>>> to 5.13->5.14->dev and the 5.14 release (probably) closes 5.13.
>>> Again, we could of course change that.
>>
>>
>> Yes, but I was attempting to describe the current approach and messed it
>> up.
>   
>> -- 
>> Kari
> 
> 
> Well, you are still right about the fact that 5.x.z is not in cherry-pick mode
> always. How it can happen that people involved in the process aren't always
> correct about branching model.  That is simply too complex to follow.

Yeah, being hard to understand is a disadvantage of the current model.

Part of the difficulty is also just the need to be aware of the current status
of the branches with respect to release status. Your cherry-pick proposal dodges
that with the keywords used in Applies-to field. It requires the bot to
understand that. If you take that away, I would guess that contributors would
not find it easier to pick all the correct branches to cherry-pick to compared
to picking the right branch to submit to.

I could imagine a similar approach used for current model to help in choosing
the right branch to submit. So picking from dev, stable, LTS and LTS-strict
would tell you the correct branch to submit to.

Also about the releases waiting for merges. Even if we have two stable branches
active and we would then have a blocker relevant for both 5.13.0 and 5.12.2,
there is no need to wait for merges. If those release branches already exist,
then they won't be merged into. So waiting for the fix to be merged into 5.13
won't change the cherry-pick operation; the two heads and the common ancestor
stay the same. Thus once the fix lands in 5.12.2, it can then be directly
cherry-picked to 5.13.0. It would have to be cherry-picked anyway.

> Btw. it also may add one merge to all merges count I mentioned befor

True.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Edward Welbourne]

Am 24.01.2019 um 10:20 schrieb Volker Hilsheimer:
 The whole notion that my change has to become someone else’s problem
 by design of the merge process is more than just a little crazy to
 me. I want to own my change, have control over which branches it
 hits, and be responsible for cleaning up the mess my change might
 have caused. The current model doesn’t give me any of that beyond
 the initial merge.

On 28 Jan 2019, at 13:27, Robert Loehning  wrote:
>>> That's laudable, but a non-professional developer who just submitted
>>> a fix and doesn't follow all the other changes going on might have a
>>> different opinion.

On 28 Jan 2019, at 13:36, Martin Smith  wrote:
>> Wouldn't we expect those external patchers to submit changes to dev
>> only? Then the module maintainer, or an LTS version maintainer (is
>> there a maintainer for each LTS version?) would decide whether the
>> change should be cherrypicked into an LTS version.

Some will do as you expect.
Others will do otherwise.

A client project, using Qt, that's opted to use our last LTS will, when
it contributes fixes to Qt that have been prompted by their need to fix
a problem Qt is causing for them, will most likely contribute their fix
targeting the LTS - they're upstreaming the fix they're using locally,
in the hopes that they'll one day stop needing to maintain that fix
themselves by patching their Qt sources.  They won't know or care about
dev.

We can, of course, ask them to deliver the fix via dev, which may
require re-working it; but they'll want to know it's going to make its
way to the LTS, because that's what they care about.

Volker Hilsheimer (28 January 2019 13:54) agreed:
> Indeed; esp in the cases where a causal contribution comes in, and
> where then the maintainers need to invest time to decide whether or
> not this is material for a stable branch, dev should be the first
> branch.

It (mostly) suits *our* needs best for everything to land in dev; but
not all potential contributors have the same priorities as us.

> A change making it into dev where it can be noticed and scrutinized by
> a bunch of people that didn’t participate in the merge request, where
> it can pass additional build and configurations, and generally be
> exposed to different cases that are not covered by CI - isn’t that
> valuable?

Yes, that is valuable; so is the stability of stable branches.

Actually scrutinising each bug-fix that's going into a stable branch in
the context of that stable branch - rather than in the context of a dev
branch, from which it's cherry-picked with less scrutiny into the stable
one - makes it less likely that we'll break the stable branch.  Users
surely have stronger expectations of stability for stable branches than
for cutting-edge first releases of a later minor version.  So breakage
in dev (caused by things merged up to it) is less harmful than breakage
in stable (caused by things cherry-picked down to it).

Which of these valuable things do we prize more highly ?

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Friday, January 25, 2019 11:50:55 AM CET Eike Ziller wrote:
> Note that this risk exists partially even if fixes are first pushed into dev
> and then from dev directly to multiple “stable” branches.
> 
> Fix goes into dev.
> Fix is cherry-picked into 5.9 without issues.
> Fix is cherry-picked into 5.12 and for whatever reason there are issues with
> that.
> 
> There is a risk that the bug will not be fixed in the next (or any) 5.12
> release even though it already is fixed in 5.9. Granted, it will be fixed
> in 5.13 again. This is also not ideal and requires release management to
> keep track of these changes to avoid it. (Some of this risk exists also for
> 5.12.x branch vs 5.12 branch, if we directly pick from dev to 5.12.x)

Yes, It may happen, but as you said in the infinity it will be fixed. Tracking 
should be quite easy, it is just a gerrit query; give me all 1 month old, open 
changes for branch 5.12.

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Friday, January 25, 2019 1:30:52 PM CET Shawn Rutledge wrote:
> > On 25 Jan 2019, at 09:43, Martin Smith  wrote:
> > 
> > 
> >> It is the absolute exception that a change goes into qtbase on first
> >> attempt.
> 
> > 
> > But many rejections have nothing to do with any change at all. I often
> > submit documentation-only changes to QtBase, and they often get tested
> > alone, with no other changes. They still get rejected multiple times
> > because test X fails this time and test Y fails next time, despite the
> > fact that my change only fixes typos in the qdoc comments. Sometimes
> > there is a compiler failure too, which is not caused by the change.
> 
> Could we simplify testing for some types of patches?  E.g. if the patch only
> touches documentation, don’t run tests, except those that involve building
> docs, if we have any of those.  (Even building the code is dubious in that
> case, as long as the bot that decides that it’s a doc-only patch actually
> verifies that the only changes are inside comments.)  If it only touches
> widgets, some time-consuming and failure-prone tests like network tests
> could be skipped.  And so on.
 
Sure, please implement it  :-). It has to be maintained on the build system 
level, so one can start already. CI can provide some magic parameters to the 
build system and then the build system can use whatever heuristic are needed 
when running "make check". I wouldn't mind that option even for local 
development.

This is out of scope for branch model discussion, for my taste :-)

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Friday, January 25, 2019 11:08:52 AM CET Lars Knoll wrote:
> 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.
> 
> 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.

Yes, yes, yes, pretty please :-)


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Robert Loehning]

Am 28.01.2019 um 14:09 schrieb Jedrzej Nowacki:
> On Friday, January 25, 2019 3:23:36 PM CET Robert Loehning wrote:
>>> Testing whether the bug that I’m fixing exists in dev or not is part of
>>> the drill of fixing bug, isn’t it? Why would you spend time on fixing
>>> something in 5.12 without checking whether the issue is still present in
>>> the latest codebase? Perhaps the issue has been fixed already, just
>>> without the author considering it relevant for 5.12 (perhaps for good
>>> reasons).
>> Why would somebody who maintains a project on Qt5 but made the decision
>> to not migrate it to Qt6 care about fixing the latter?
>>
>> Cheers,
>> Robert
> 
> Project that is not being updated is not maintained. Not maintained projects
> should not take part of the mainstream.
> 
> Cheers,
>Jędrek
> 
> 

I mean an external project which is based on Qt, like some commercial 
application. Say they decided - for good or bad reasons - that they will 
not migrate to Qt 6, but they require a fix in Qt 5. They even provide 
this fix, but why would they care about making it work in Qt 6?

Cheers,
Robert
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Thursday, January 24, 2019 2:35:51 PM CET Allan Sandfeld Jensen wrote:
> We can't integrate multiple changes to the same branch in parellel. So you
> can't start using more resources to speed things up. (9 women to have a
> child in 1 month) The only way to speed up CI integration is to be merging
> to different branches, that way we CAN have multiple integrations running
> in parallel.

Well, I can use more resources. We can build on stronger machines CPU limits 
are quite arbitrary. We could build tests during build phase (it means more 
CPU power, Aapo is currently pushing the task forward). In the end we could 
execute tests on multiple machines (it is an old idea, that was just down-
prioritized).

/side note:  The fact that we do not run multiple integration in parallel for 
one branch is super annoying to me, it is just waste of time, we should change 
it. As far I know we are doing it only to avoid potential breakages caused by 
two concurrent change, in my opinion cost / gain ratio is terrible. Again that 
is another discussion.

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Thursday, January 24, 2019 7:46:35 PM CET Sergio Ahumada wrote:
> On 24.01.19 14:10, Edward Welbourne wrote:
> > Automated cherry-picking implies various complications that we haven't
> > fully explored; whereas merges have some well-established reliable
> > properties that avoid many of those complications.  Engineers prefer
> > what's known, from experience, to work over things that sound like they
> > might.  OTOH, as Ville points out, other projects do use cherry-picking;
> > so perhaps we need more information from such projects,
> 
> I have seen this implemented, similar to what Jedrek proposed, but the
> decision where to cherry pick is in JIRA, not via git annotations/marks.
> 
> This requires the Release Manager to keep an eye on which changes have
> not being propagated to all branches, though.
> 
> fully automated process, the fix is pushed to the oldest branch (5.12)
> and then propagated to newer versions (5.13, dev, etc). Change is
> automatically cherry-picked, updated the commit message, uploaded to
> gerrit, automatic Code-Review+2, automatic stage, automatically merged
> if CI passes.
> 
> propagation rate failure is around 20% of, mostly due to:
> - merge conflicts (will happen, for sure)
> -- genuine merge conflicts
> -- change was already cherry-picked manually
> -- dependencies missing
> - ci failures
> -- mostly due to infrastructure issues
> -- ci does not know how to handle dependencies
> 
> advantages:
> - when it works, everybody is happy
> - pass rate is very high (around 80%)
> - one can run git-cherry-pick -n and add additional info in the commit
> message
> - can be tuned up to exclude some changes from being propagated (the
> bot, not git-cherry-pick itself)
> 
> disadvantages:
> - most developers don't know how to handle the propagation failures
> -- I already moved on and am working on something else, do you want me
> to switch to '5.19' to fix a change I did in '5.12' ? oh, and it failed
> in '5.18' as well? why don't you do merges instead and leave alone?
> [true story :-)]
> - change can pass the CI and found to be problematic later on
> -- oh, I need to fix my change in 5 branches now? [Gerrit 2.14 has a
> cherry-pick button in the UI now, so this is not a problem with that
> version]
> - automated cherry-pick process/bot/script has to be maintained
> -- one change not merged might lead to lots of changes to fail with
> merge conflicts, staying open in gerrit forever
> -- hey, can you add intelligence to the bot so it know how to merge the
> open changes once the dependency is merged?
> -- hey, can you add intelligence to the bot so it can cherry-pick them
> in the right order?)
> - yes, git-cherry-pick does weird things. I have seen it cherry-picking
> the same change twice without problems (same line twice in the file, I
> think I was an include guard that compiled but behaved weirdly, or similar)
> 
> my 2€

Thank you for the story, do I get it correctly that the most of problems are 
social and global flakiness of the system?

Cheers,
  Jędrek



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Volker Hilsheimer]

> On 28 Jan 2019, at 14:03, Robert Loehning  wrote:
> Am 28.01.2019 um 13:54 schrieb Volker Hilsheimer:
>>> On 28 Jan 2019, at 13:36, Martin Smith  wrote:
 On 28 Jan 2019, at 13:27, Robert Loehning  wrote:
> Am 24.01.2019 um 10:20 schrieb Volker Hilsheimer:
>> On 24 Jan 2019, at 08:03, Olivier Goffart  wrote:
>> [...]>- Stay with the current solution <= the merge effort is too 
>> big and qt6 is
>>> expected to cause conflicts that really should not be solved by one 
>>> person
>> 
>> Again, I don't see how the proposed model reduce the amount of conflicts.
>> If the "one person" is the problem, then nothing prevents you to assign 
>> more people to the job. One easy way is already to share the different 
>> modules (repositories). But with some cooperation it is also possible to 
>> share the work accross directories, or by number of commits. One can 
>> also be pragmatic and revert most problematic commit (that fails tests) 
>> in dev or stable, then let the author work at it again.
> 
> Having to wait for someone else to trigger the merge and resolve the 
> various conflicts before I can continue to base my work on dev on a fix 
> that I already made in 5.12 breaks flow. Distributing this work to more 
> people doesn’t solve the problem.
> 
> The whole notion that my change has to become someone else’s problem by 
> design of the merge process is more than just a little crazy to me. I 
> want to own my change, have control over which branches it hits, and be 
> responsible for cleaning up the mess my change might have caused. The 
> current model doesn’t give me any of that beyond the initial merge.
 
 That's laudable, but a non-professional developer who just submitted a
 fix and doesn't follow all the other changes going on might have a
 different opinion.
 
>> 
>>> Wouldn't we expect those external patchers to submit changes to dev only? 
>>> Then the module maintainer, or an LTS version maintainer (is there a 
>>> maintainer for each LTS version?) would decide whether the change should be 
>>> cherrypicked into an LTS version.
>>> 
>>> martin
>> 
>> 
>> Indeed; esp in the cases where a causal contribution comes in, and where 
>> then the maintainers need to invest time to decide whether or not this is 
>> material for a stable branch, dev should be the first branch.
> 
> In the new model, dev should always be the first branch. Would we then 
> have some changes for which picking and resolving conflicts is expected 
> to be done by the author, some for which it is expected to be done by 
> the maintainers and a gray area between those?

I think “it depends”, and it’ll be a matter of negotiation. The worst case 
scenario in case of cherry-pick-conflict is “we couldn’t agree on whether it 
should go into stable, or we couldn’t find anyone to port it back, so it’ll 
only be in the next minor release”. That’s not such a terrible "worst case”, I 
think.

Making the merge into dev independent of that discussion at least keeps things 
moving forward. If then the author doesn’t want to spend time on backporting 
and conflict resolving, but there are lots of users and customers asking for 
the fix, then that’s a matter of finding someone else to pick up the challenge.


Of course, doing it like what Jędrek (IIRC) reported from the Python community 
and leaving it to the maintainers to take things down into stable branches is 
one way. Then maintainers have control over the order and timing, and can 
perhaps avoid a lot of mess that way.


Volker

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Friday, January 25, 2019 3:23:36 PM CET Robert Loehning wrote:
> > Testing whether the bug that I’m fixing exists in dev or not is part of
> > the drill of fixing bug, isn’t it? Why would you spend time on fixing
> > something in 5.12 without checking whether the issue is still present in
> > the latest codebase? Perhaps the issue has been fixed already, just
> > without the author considering it relevant for 5.12 (perhaps for good
> > reasons).
> Why would somebody who maintains a project on Qt5 but made the decision
> to not migrate it to Qt6 care about fixing the latter?
> 
> Cheers,
> Robert

Project that is not being updated is not maintained. Not maintained projects 
should not take part of the mainstream.

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

On Thursday, January 24, 2019 3:18:59 PM CET Kari Oikarinen wrote:
> On 24.1.2019 16.15, Edward Welbourne wrote:
> 
> > Kari Oikarinen (24 January 2019 15:02)
> > 
> >> The rest of the paragraph talks about a situation where we will have two
> >> stable
 branches alive at the same time. Typically we don't, because
> >> once 5.x+1 is created, 5.x is closed.
> > 
> > 
> > Not quite: once 5.x+1 is *released*, 5.x (if not LTS) is closed
> > (unless we have a pressing reason to release another 5.x.y).
> > So, in the interval between 5.x+1 branching and releasing,
> > we have three branches.
> 
> 
> Right, so typically we indeed have two stable branches open. Thanks for 
> correcting me.
> 
> 
> > 
> > 
> >> But 5.12 is an LTS version, so it will still stay open.
> > 
> > 
> > Indeed.
> > 
> > 
> >> But at what point (under current process) would be switch it to
> >> cherry-pick only
 mode? I don't remember when it happened for 5.9. It
> >> could be when 5.13 is created and then there would be no release blocked
> >> by waiting for a merge.> 
> > 
> > We switch to cherry-picking into 5.12 when 5.14 is created.
> > See QUIP-5,
> > * https://quips-qt-io.herokuapp.com/quip-0005.html
> > 
> > So creation of 5.14 switches our merge pattern from 5.12->5.13->dev
> > to 5.13->5.14->dev and the 5.14 release (probably) closes 5.13.
> > Again, we could of course change that.
> 
> 
> Yes, but I was attempting to describe the current approach and messed it
> up.
 
> -- 
> Kari


Well, you are still right about the fact that 5.x.z is not in cherry-pick mode 
always. How it can happen that people involved in the process aren't always 
correct about branching model.  That is simply too complex to follow.

Btw. it also may add one merge to all merges count I mentioned before.

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Robert Loehning]

Am 28.01.2019 um 13:54 schrieb Volker Hilsheimer:
>> On 28 Jan 2019, at 13:36, Martin Smith  wrote:
>>> On 28 Jan 2019, at 13:27, Robert Loehning  wrote:
 Am 24.01.2019 um 10:20 schrieb Volker Hilsheimer:
> On 24 Jan 2019, at 08:03, Olivier Goffart  wrote:
> [...]>- Stay with the current solution <= the merge effort is too big 
> and qt6 is
>> expected to cause conflicts that really should not be solved by one 
>> person
>
> Again, I don't see how the proposed model reduce the amount of conflicts.
> If the "one person" is the problem, then nothing prevents you to assign 
> more people to the job. One easy way is already to share the different 
> modules (repositories). But with some cooperation it is also possible to 
> share the work accross directories, or by number of commits. One can also 
> be pragmatic and revert most problematic commit (that fails tests) in dev 
> or stable, then let the author work at it again.

 Having to wait for someone else to trigger the merge and resolve the 
 various conflicts before I can continue to base my work on dev on a fix 
 that I already made in 5.12 breaks flow. Distributing this work to more 
 people doesn’t solve the problem.

 The whole notion that my change has to become someone else’s problem by 
 design of the merge process is more than just a little crazy to me. I want 
 to own my change, have control over which branches it hits, and be 
 responsible for cleaning up the mess my change might have caused. The 
 current model doesn’t give me any of that beyond the initial merge.
>>>
>>> That's laudable, but a non-professional developer who just submitted a
>>> fix and doesn't follow all the other changes going on might have a
>>> different opinion.
>>>
> 
>> Wouldn't we expect those external patchers to submit changes to dev only? 
>> Then the module maintainer, or an LTS version maintainer (is there a 
>> maintainer for each LTS version?) would decide whether the change should be 
>> cherrypicked into an LTS version.
>>
>> martin
> 
> 
> Indeed; esp in the cases where a causal contribution comes in, and where then 
> the maintainers need to invest time to decide whether or not this is material 
> for a stable branch, dev should be the first branch.

In the new model, dev should always be the first branch. Would we then 
have some changes for which picking and resolving conflicts is expected 
to be done by the author, some for which it is expected to be done by 
the maintainers and a gray area between those?

> A change making it into dev where it can be noticed and scrutinized by a 
> bunch of people that didn’t participate in the merge request, where it can 
> pass additional build and configurations, and generally be exposed to 
> different cases that are not covered by CI - isn’t that valuable?
> 
> 
> Volker
> 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Volker Hilsheimer]

> On 28 Jan 2019, at 13:36, Martin Smith  wrote:
>> On 28 Jan 2019, at 13:27, Robert Loehning  wrote:
>>> Am 24.01.2019 um 10:20 schrieb Volker Hilsheimer:
 On 24 Jan 2019, at 08:03, Olivier Goffart  wrote:
 [...]>- Stay with the current solution <= the merge effort is too big 
 and qt6 is
> expected to cause conflicts that really should not be solved by one person
 
 Again, I don't see how the proposed model reduce the amount of conflicts.
 If the "one person" is the problem, then nothing prevents you to assign 
 more people to the job. One easy way is already to share the different 
 modules (repositories). But with some cooperation it is also possible to 
 share the work accross directories, or by number of commits. One can also 
 be pragmatic and revert most problematic commit (that fails tests) in dev 
 or stable, then let the author work at it again.
>>> 
>>> Having to wait for someone else to trigger the merge and resolve the 
>>> various conflicts before I can continue to base my work on dev on a fix 
>>> that I already made in 5.12 breaks flow. Distributing this work to more 
>>> people doesn’t solve the problem.
>>> 
>>> The whole notion that my change has to become someone else’s problem by 
>>> design of the merge process is more than just a little crazy to me. I want 
>>> to own my change, have control over which branches it hits, and be 
>>> responsible for cleaning up the mess my change might have caused. The 
>>> current model doesn’t give me any of that beyond the initial merge.
>> 
>> That's laudable, but a non-professional developer who just submitted a
>> fix and doesn't follow all the other changes going on might have a
>> different opinion.
>> 

> Wouldn't we expect those external patchers to submit changes to dev only? 
> Then the module maintainer, or an LTS version maintainer (is there a 
> maintainer for each LTS version?) would decide whether the change should be 
> cherrypicked into an LTS version.
> 
> martin


Indeed; esp in the cases where a causal contribution comes in, and where then 
the maintainers need to invest time to decide whether or not this is material 
for a stable branch, dev should be the first branch.

A change making it into dev where it can be noticed and scrutinized by a bunch 
of people that didn’t participate in the merge request, where it can pass 
additional build and configurations, and generally be exposed to different 
cases that are not covered by CI - isn’t that valuable?


Volker

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Martin Smith]

>That's laudable, but a non-professional developer who just submitted a
>fix and doesn't follow all the other changes going on might have a
>different opinion.

Wouldn't we expect those external patchers to submit changes to dev only? Then 
the module maintainer, or an LTS version maintainer (is there a maintainer for 
each LTS version?) would decide whether the change should be cherrypicked into 
an LTS version.

martin


From: Development  on behalf of Robert 
Loehning 
Sent: Monday, January 28, 2019 1:27:20 PM
To: Volker Hilsheimer
Cc: Qt development mailing list
Subject: Re: [Development] Proposal: New branch model

Am 24.01.2019 um 10:20 schrieb Volker Hilsheimer:
>> On 24 Jan 2019, at 08:03, Olivier Goffart  wrote:
>> [...]>- Stay with the current solution <= the merge effort is too big 
>> and qt6 is
>>> expected to cause conflicts that really should not be solved by one person
>>
>> Again, I don't see how the proposed model reduce the amount of conflicts.
>> If the "one person" is the problem, then nothing prevents you to assign more 
>> people to the job. One easy way is already to share the different modules 
>> (repositories). But with some cooperation it is also possible to share the 
>> work accross directories, or by number of commits. One can also be pragmatic 
>> and revert most problematic commit (that fails tests) in dev or stable, then 
>> let the author work at it again.
>
> Having to wait for someone else to trigger the merge and resolve the various 
> conflicts before I can continue to base my work on dev on a fix that I 
> already made in 5.12 breaks flow. Distributing this work to more people 
> doesn’t solve the problem.
>
> The whole notion that my change has to become someone else’s problem by 
> design of the merge process is more than just a little crazy to me. I want to 
> own my change, have control over which branches it hits, and be responsible 
> for cleaning up the mess my change might have caused. The current model 
> doesn’t give me any of that beyond the initial merge.

That's laudable, but a non-professional developer who just submitted a
fix and doesn't follow all the other changes going on might have a
different opinion.

Cheers,
Robert


--
   Robert Löhning, Software Engineer - The Qt Company GmbH
   The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
   Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
   Sitz der Gesellschaft: Berlin,
   Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Robert Loehning]

Am 24.01.2019 um 10:20 schrieb Volker Hilsheimer:
>> On 24 Jan 2019, at 08:03, Olivier Goffart  wrote:
>> [...]>- Stay with the current solution <= the merge effort is too big 
>> and qt6 is
>>> expected to cause conflicts that really should not be solved by one person
>>
>> Again, I don't see how the proposed model reduce the amount of conflicts.
>> If the "one person" is the problem, then nothing prevents you to assign more 
>> people to the job. One easy way is already to share the different modules 
>> (repositories). But with some cooperation it is also possible to share the 
>> work accross directories, or by number of commits. One can also be pragmatic 
>> and revert most problematic commit (that fails tests) in dev or stable, then 
>> let the author work at it again.
> 
> Having to wait for someone else to trigger the merge and resolve the various 
> conflicts before I can continue to base my work on dev on a fix that I 
> already made in 5.12 breaks flow. Distributing this work to more people 
> doesn’t solve the problem.
> 
> The whole notion that my change has to become someone else’s problem by 
> design of the merge process is more than just a little crazy to me. I want to 
> own my change, have control over which branches it hits, and be responsible 
> for cleaning up the mess my change might have caused. The current model 
> doesn’t give me any of that beyond the initial merge.

That's laudable, but a non-professional developer who just submitted a 
fix and doesn't follow all the other changes going on might have a 
different opinion.

Cheers,
Robert


-- 
   Robert Löhning, Software Engineer - The Qt Company GmbH
   The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
   Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
   Sitz der Gesellschaft: Berlin,
   Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Robert Loehning]

Am 28.01.2019 um 11:11 schrieb Edward Welbourne:
> Am 25.01.2019 um 11:08 schrieb Lars Knoll:
>>> 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).
> 
> My working guess at what the present system does is that it piles up a
> staging branch with everything that gets staged while an integration is
> running; when one integration completes (with maybe some modest delay if
> the staging branch is sort), the staging branch gets its turn to attempt
> to integrate (possibly via a rebase onto a freshly-integrated branch).
> I hope someone who knows the actual process can describe it in this
> thread.
> 
> If that's reasonably close to true, the we shall indeed get many commits
> piling up in each staging branch, increasing the likelihood of failure
> in the integration attempt.  We could mitigate that in various ways by
> tweaking the process.
> 
> In particular, we could cap the length of staging branches (perhaps with
> a bit of flexibility to let in commits with the same owner as some
> already in the branch, so that groups of related changes don't get split
> up); once a staging branch hits the cap, we start a fresh staging
> branch.  This gives us a queue of staging branches, rather than just
> one, each waiting to be integrated.
> 
>>> 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
> 
> We could equally run several integrations in parallel and select one of
> those that succeed (probably the one that entered the staging queue
> earliest) to be the new tip; all others that succeed, plus any new
> staging branches grown in the interval, get rebased onto that and tested
> in parallel again.  That'll be "wasteful" of Coin resources in so far as
> some branches pass repeatedly before getting accepted, but it'll avoid
> the small risk you describe below.  The "speculative" integrations being
> run in parallel with the "will win if several succeed" one make the most
> of Coin having the capacity to run several in parallel - assuming it does.
> 
>>> 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.
> 
> When those events happen, they're going to gum up the whole works until
> they're sorted out; they require manual intervention, Which Is Bad.
> 
> Robert Loehning (25 January 2019 17:49) replied
>> 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.
> 
> IIUC, you're describing a two-stage integration process; test many
> staging branches in parallel; accumulate successes; combine those and
> re-test; if good, keep.  There shall be new staging branches coming out
> of the sausage machine while the earlier composite is going.  We have to
> work out what to do with those.  If the composite fails, these fresh
> successes can be combined and tested just as the earlier one was; but,
> if the earlier composite passes, we need to rebase the integrations that
> have passed while it was tested.  However, all these have passed
> previously, so we have fair confidence in them; so we can combine them
> all together on the prior composite and set about testing this as a
> second-stage composite integration.  So I think that has a good chance
> of working well.
> 
> A note on merge vs rebase here: when merging several branches that have
> passed first-integration, a conflict excludes a whole branch, though
> it's 

Re: [Development] Proposal: New branch model

[Edward Welbourne]

Am 25.01.2019 um 11:08 schrieb Lars Knoll:
>> 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).

My working guess at what the present system does is that it piles up a
staging branch with everything that gets staged while an integration is
running; when one integration completes (with maybe some modest delay if
the staging branch is sort), the staging branch gets its turn to attempt
to integrate (possibly via a rebase onto a freshly-integrated branch).
I hope someone who knows the actual process can describe it in this
thread.

If that's reasonably close to true, the we shall indeed get many commits
piling up in each staging branch, increasing the likelihood of failure
in the integration attempt.  We could mitigate that in various ways by
tweaking the process.

In particular, we could cap the length of staging branches (perhaps with
a bit of flexibility to let in commits with the same owner as some
already in the branch, so that groups of related changes don't get split
up); once a staging branch hits the cap, we start a fresh staging
branch.  This gives us a queue of staging branches, rather than just
one, each waiting to be integrated.

>> 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

We could equally run several integrations in parallel and select one of
those that succeed (probably the one that entered the staging queue
earliest) to be the new tip; all others that succeed, plus any new
staging branches grown in the interval, get rebased onto that and tested
in parallel again.  That'll be "wasteful" of Coin resources in so far as
some branches pass repeatedly before getting accepted, but it'll avoid
the small risk you describe below.  The "speculative" integrations being
run in parallel with the "will win if several succeed" one make the most
of Coin having the capacity to run several in parallel - assuming it does.

>> 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.

When those events happen, they're going to gum up the whole works until
they're sorted out; they require manual intervention, Which Is Bad.

Robert Loehning (25 January 2019 17:49) replied
> 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.

IIUC, you're describing a two-stage integration process; test many
staging branches in parallel; accumulate successes; combine those and
re-test; if good, keep.  There shall be new staging branches coming out
of the sausage machine while the earlier composite is going.  We have to
work out what to do with those.  If the composite fails, these fresh
successes can be combined and tested just as the earlier one was; but,
if the earlier composite passes, we need to rebase the integrations that
have passed while it was tested.  However, all these have passed
previously, so we have fair confidence in them; so we can combine them
all together on the prior composite and set about testing this as a
second-stage composite integration.  So I think that has a good chance
of working well.

A note on merge vs rebase here: when merging several branches that have
passed first-integration, a conflict excludes a whole branch, though
it's probably caused by one or few of the commits in the branch; whereas
rebasing lets you detect which individual commits cause the conflicts,
so that only these get left out.  It also gives you a 

Re: [Development] Proposal: New branch model

[Thiago Macieira]

On Friday, 25 January 2019 04:30:52 PST Shawn Rutledge wrote:
> Could we simplify testing for some types of patches?  E.g. if the patch only
> touches documentation, don’t run tests, except those that involve building
> docs, if we have any of those.

I think that's a good idea to investigate, but remember that you *can* break 
things with doc changes. Maybe a way for a "low-priority stage", which stages 
a change but doesn't trigger the integration unless a timeout comes around or 
a regular priority change is also staged.

One time back in the TT/Nokia days Frans asked me for a quick review of a "### 
Qt5" change he wanted to add and I gave him my approval verbally (that was 
before code review systems). So he pushed it. 5 minutes later, Paul waked into 
our office saying we had broken the build: we forgot the // to *start* the 
comment.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Thiago Macieira]

On Friday, 25 January 2019 01:10:35 PST Simon Hausmann wrote:
> 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.

I vaguely remember it. But your bringing it up is *not* an argument in favour 
of cherry-picking. Doing backporting properly in the Perforce days was a 
nightmare. We did not consistently backport fixes to earlier releases, even 
when we had a somewhat long stable series (4.3 went through 4.3.5).

Also, unlike Git, Perforce "merges" *were* a series of cherry-picks and it did 
know which commits had been cherry-picked and which ones hadn't. So if you 
told it to merge a range, it would tell you everything that was missing. More 
importantly, the range did not have to be contiguous, so you could cherry-pick 
only your own changes and let others deal with theirs. It also helped p4 had a 
pretty good automated conflict resolution in the command-line (today, I use 
kdiff3 for that, via git mergetool).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [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 
> mailto:simon.hausm...@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 
>> mailto:ville.voutilai...@gmail.com>> wrote:
>>
>> On Thu, 24 Jan 2019 at 20:26, Simon Hausmann 
>> mailto:simon.hausm...@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, a

Re: [Development] Proposal: New branch model

[Robert Loehning]

Am 24.01.2019 um 10:39 schrieb Volker Hilsheimer:
>> On 24 Jan 2019, at 09:22, Jaroslaw Kobus  wrote:
 "All(**) changes would go to dev. From which they would be automatically
 cherry-picked by a bot to other branches. The decision to which branch 
 cherry-
 pick, would be taken based on a tag in the commit message. We could add a
 footer that marks the change risk level as in quip-5"

 No sure I understand the above correctly. Let's say in dev branch some 
 source file got refactored completely, so that no single line match the 
 old version anymore, e.g. Qt 5.9. Now you need to fix the old code, which 
 is in 5.9 branch - how in this case you may try to push your fix to dev?

 Jarek

>>> That’s where the “with exception of branch specific changes” clause (which 
>>> the ** points at) kicks in.
>>>
>>> Is the fix needed in dev (or is the bug fixed by the refactoring)?
>>>
>>> If yes, then fix it in dev, and then make a separate fix in the relevant 
>>> LTS branches (perhaps starting with the cherry-pick’ed change). Or just 
>>> accept that this bug won’t/can’t be fixed in the pre-refactoring codebase.
>>>
>>> If no, then push the fix for the newest branch where it’s needed, from 
>>> where it can be cherry picked further; don’t do anything in dev (including 
>>> “don’t expect someone that knows nothing about your change to deal with the 
>>> merge conflict”).
>>>
>> In this case there is additional step then. You would be forced now to check 
>> first both 5.9 and dev branches and detect if a fix would be "applyable" to 
>> the dev or not.
> 
> 
> Testing whether the bug that I’m fixing exists in dev or not is part of the 
> drill of fixing bug, isn’t it? Why would you spend time on fixing something 
> in 5.12 without checking whether the issue is still present in the latest 
> codebase? Perhaps the issue has been fixed already, just without the author 
> considering it relevant for 5.12 (perhaps for good reasons).

Why would somebody who maintains a project on Qt5 but made the decision 
to not migrate it to Qt6 care about fixing the latter?

Cheers,
Robert

>> Besides, if you decide that your fix goes only to the 5.9 branch - in this 
>> case you follow the current model anyway, right? So, having two models isn't 
>> better than having just one I think.
> 
> 
> With the proposed model there are no more automatic merges from more stable 
> to less stable, so once my change made it into 5.9, that is it.
> 
> 
> Volker
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Edward Welbourne]

On 25 Jan 2019, at 10:10, Simon Hausmann 
mailto:simon.hausm...@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.

Lars Knoll (25 January 2019 11:08)
> 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.

It should be fairly trivial to ensure we tag the cherry-picks in such a
way that some routine script can alert relevant folk to ones that
haven't been sorted out within a month, or before the next release on
the branch they targeted.  I think this is less of a reason to worry
than you suppose.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Shawn Rutledge]

> On 25 Jan 2019, at 09:43, Martin Smith  wrote:
> 
>> It is the absolute exception that a change goes into qtbase on first attempt.
> 
> But many rejections have nothing to do with any change at all. I often submit 
> documentation-only changes to QtBase, and they often get tested alone, with 
> no other changes. They still get rejected multiple times because test X fails 
> this time and test Y fails next time, despite the fact that my change only 
> fixes typos in the qdoc comments. Sometimes there is a compiler failure too, 
> which is not caused by the change.

Could we simplify testing for some types of patches?  E.g. if the patch only 
touches documentation, don’t run tests, except those that involve building 
docs, if we have any of those.  (Even building the code is dubious in that 
case, as long as the bot that decides that it’s a doc-only patch actually 
verifies that the only changes are inside comments.)  If it only touches 
widgets, some time-consuming and failure-prone tests like network tests could 
be skipped.  And so on.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Eike Ziller]

> On 25. Jan 2019, at 11:08, Lars Knoll  wrote:
> 
> 
> 
>> On 25 Jan 2019, at 10: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.
> 
> 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.

Note that this risk exists partially even if fixes are first pushed into dev 
and then from dev directly to multiple “stable” branches.

Fix goes into dev.
Fix is cherry-picked into 5.9 without issues.
Fix is cherry-picked into 5.12 and for whatever reason there are issues with 
that.

There is a risk that the bug will not be fixed in the next (or any) 5.12 
release even though it already is fixed in 5.9. Granted, it will be fixed in 
5.13 again.
This is also not ideal and requires release management to keep track of these 
changes to avoid it.
(Some of this risk exists also for 5.12.x branch vs 5.12 branch, if we directly 
pick from dev to 5.12.x)

> 
>> (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.
> 
> 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  
>> > wrote:
>> > 
>> > On Thu, 24 Jan 2019 at 20:26, Simon Hausmann  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

Re: [Development] Proposal: New branch model

[Lars Knoll]

On 25 Jan 2019, at 10:10, Simon Hausmann 
mailto:simon.hausm...@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.

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 
> mailto:ville.voutilai...@gmail.com>> wrote:
>
> On Thu, 24 Jan 2019 at 20:26, Simon Hausmann 
> mailto:simon.hausm...@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 

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

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  
>>> wrote:
>>> 
>>> On Thu, 24 Jan 2019 at 20:26, Simon Hausmann  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
&

Re: [Development] Proposal: New branch model

[Simon Hausmann]

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  
>> wrote:
>>
>> On Thu, 24 Jan 2019 at 20:26, Simon Hausmann  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

Re: [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  
>> wrote:
>> 
>> On Thu, 24 Jan 2019 at 20:26, Simon Hausmann  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 

Re: [Development] Proposal: New branch model

[Simon Hausmann]

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  
> wrote:
>
> On Thu, 24 Jan 2019 at 20:26, Simon Hausmann  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@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Paul Tvete]

On Friday, 25 January 2019 09:05:45 CET Lars Knoll wrote:
> * 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.

This could also be accomplished by moving the change to the correct branch in 
gerrit as part of the review process.

Currently, only the owner can ask the bot to move the change, but since this 
is our bot I assume that we can change that policy.

- Paul


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Martin Smith]

>It is the absolute exception that a change goes into qtbase on first attempt.

But many rejections have nothing to do with any change at all. I often submit 
documentation-only changes to QtBase, and they often get tested alone, with no 
other changes. They still get rejected multiple times because test X fails this 
time and test Y fails next time, despite the fact that my change only fixes 
typos in the qdoc comments. Sometimes there is a compiler failure too, which is 
not caused by the change.

Maybe we should have a regular cron job that just runs an empty change through 
the system to see what tests, compilers, etc are failing and flag them for 
fixing.

And I suppose the cherrypicks to stable branches should not be triggered until 
the change has passed in the dev branch.

martin


From: Development  on behalf of Simon 
Hausmann 
Sent: Friday, January 25, 2019 9:25:16 AM
To: Allan Sandfeld Jensen; Jedrzej Nowacki
Cc: development@qt-project.org
Subject: Re: [Development] Proposal: New branch model


I'm somewhat attracted to the proposed model, in conjunction with automation 
and by treating Qt6 differently.


However Allan's last point is what sticks to me most, the load on the CI and 
the resulting impact on productivity:


If all it would take to get changes distributed is a cherry-pick, then I can 
totally see how this can fly. However with a blocking CI and the rate of 
flakyness we are experiencing at least in qtbase, I think this carries a high 
risk of slowing down development.


It is the absolute exception that a change goes into qtbase on first attempt. 
I'd say that in average perhaps three attempts of staging are needed. Currently 
the batches of integrations are distributed among the release branch (5.12.x), 
5.12 and dev. With all changes going to dev first, the size of batches is going 
to increase as well as the frequency of integration attempts for the same 
branch. This either increases the change of rejection of your change to due an 
unrelated change (as the batches are bigger) or it will take longer before your 
change gets tried. That would seem like a slow down to me and also not 
something that helps casual first-time contributors.


I would love to hear the opinion from frequent qtbase submitters on the 
proposal and how they feel about this.



Liang's email weighs a lot in my opinion. And Sergio's and Ville's experience 
with this model as well. I think that we should try this with a release branch 
first before we go all in. It would seem that quite a bit of tooling needs to 
be developed first anyway?




Simon


From: Development  on behalf of Allan 
Sandfeld Jensen 
Sent: Thursday, January 24, 2019 1:33:28 PM
To: Jedrzej Nowacki
Cc: development@qt-project.org
Subject: Re: [Development] Proposal: New branch model

On Donnerstag, 24. Januar 2019 13:27:41 CET Jedrzej Nowacki wrote:
> Dnia środa, 23 stycznia 2019 22:04:16 CET Allan Sandfeld Jensen pisze:
>
> > On Mittwoch, 23. Januar 2019 16:51:10 CET Jedrzej Nowacki wrote:
> >
> > >   Proposal in short: let's use cherry-pick mode everywhere.
> > >
> > >   All(**) changes would go to dev. From which they would be
> > >   automatically
> > >
> > >
> > > cherry-picked by a bot to other branches. The decision to which branch
> > > cherry-
> >
> >
> >
> >  pick, would be taken based on a tag in the commit message. We
> >
> >
> >
> > > could add a footer that marks the change risk level as in quip-5
> > > (http://quips-qt-io.herokuapp.com/quip-0005.html), so for example
> > > "dev",
> > > "stable", "LTS". By default everything would be cherry-picked to qt6
> > > branch
> > > unless "no-future" tag would be given. Of course we can bike-shed about
> > > the
> > > tag names.
> >
> >
> > I don't see any advantage to this what so ever. The same amount of work
> > and
 refactoring needs to be done, all you have done is made development
> > more prone to human error, and fixes less likely to reach their intended
> > target, and made getting point releases out on time harder as they need
> > to go through more steps before they have all their patches in.
> >
> > 'Allan
>
>
>
> It is hard to answer this because you have forgotten to write why you think
>
 that development would be more error prone or fixes less likely to reach
> the destination or more steps would be involved in releasing. So I will try
> shooting in the dark :-)
>
> The current merging strategy involves couple of people, one merge master and
> a
 random reviewer that looks at conflicts if there are any. Usually it is
> not even close to quality level we have for

Re: [Development] Proposal: New branch model

[Simon Hausmann]

I'm somewhat attracted to the proposed model, in conjunction with automation 
and by treating Qt6 differently.


However Allan's last point is what sticks to me most, the load on the CI and 
the resulting impact on productivity:


If all it would take to get changes distributed is a cherry-pick, then I can 
totally see how this can fly. However with a blocking CI and the rate of 
flakyness we are experiencing at least in qtbase, I think this carries a high 
risk of slowing down development.


It is the absolute exception that a change goes into qtbase on first attempt. 
I'd say that in average perhaps three attempts of staging are needed. Currently 
the batches of integrations are distributed among the release branch (5.12.x), 
5.12 and dev. With all changes going to dev first, the size of batches is going 
to increase as well as the frequency of integration attempts for the same 
branch. This either increases the change of rejection of your change to due an 
unrelated change (as the batches are bigger) or it will take longer before your 
change gets tried. That would seem like a slow down to me and also not 
something that helps casual first-time contributors.


I would love to hear the opinion from frequent qtbase submitters on the 
proposal and how they feel about this.



Liang's email weighs a lot in my opinion. And Sergio's and Ville's experience 
with this model as well. I think that we should try this with a release branch 
first before we go all in. It would seem that quite a bit of tooling needs to 
be developed first anyway?




Simon


From: Development  on behalf of Allan 
Sandfeld Jensen 
Sent: Thursday, January 24, 2019 1:33:28 PM
To: Jedrzej Nowacki
Cc: development@qt-project.org
Subject: Re: [Development] Proposal: New branch model

On Donnerstag, 24. Januar 2019 13:27:41 CET Jedrzej Nowacki wrote:
> Dnia środa, 23 stycznia 2019 22:04:16 CET Allan Sandfeld Jensen pisze:
>
> > On Mittwoch, 23. Januar 2019 16:51:10 CET Jedrzej Nowacki wrote:
> >
> > >   Proposal in short: let's use cherry-pick mode everywhere.
> > >
> > >   All(**) changes would go to dev. From which they would be
> > >   automatically
> > >
> > >
> > > cherry-picked by a bot to other branches. The decision to which branch
> > > cherry-
> >
> >
> >
> >  pick, would be taken based on a tag in the commit message. We
> >
> >
> >
> > > could add a footer that marks the change risk level as in quip-5
> > > (http://quips-qt-io.herokuapp.com/quip-0005.html), so for example
> > > "dev",
> > > "stable", "LTS". By default everything would be cherry-picked to qt6
> > > branch
> > > unless "no-future" tag would be given. Of course we can bike-shed about
> > > the
> > > tag names.
> >
> >
> > I don't see any advantage to this what so ever. The same amount of work
> > and
 refactoring needs to be done, all you have done is made development
> > more prone to human error, and fixes less likely to reach their intended
> > target, and made getting point releases out on time harder as they need
> > to go through more steps before they have all their patches in.
> >
> > 'Allan
>
>
>
> It is hard to answer this because you have forgotten to write why you think
>
 that development would be more error prone or fixes less likely to reach
> the destination or more steps would be involved in releasing. So I will try
> shooting in the dark :-)
>
> The current merging strategy involves couple of people, one merge master and
> a
 random reviewer that looks at conflicts if there are any. Usually it is
> not even close to quality level we have for single patches in which we have
> more reviewers and gerrit shows the real diff. In practice we assume that
> no conflicts == good merge.
>
> Fixes are less likely to hit target branches, true, but only if nobody
> cares.
 Mark that a fix can magically disappear during broken mere, nobody
> will see it. The proposed solution allows at least track such cases.
>
> Releases branches already use cherry-pick mode so from that perspective
> there
 is no big changes, the only one is the origin branch from which the
> cherry- pick should happen.
>
Yeah, this was no the best of comments on the issue. But I believe I wrote my
objections elsewhere:
- Cherry-picks are more error prone in git than merges and requires manual
intervention more frequently
- Even if we accept the always and instantly cherry-pick model, there is no
reason to push to dev, continuing to push to the same branches as now could
achieve all the same things with less room for error (because where it is
supposed to be merged to is both implicit and unambigious

Re: [Development] Proposal: New branch model

[Simon Hausmann]

It's a fair point to raise.


The closest scenario that I can think of that we've had in the past with a long 
living branch was 5.6 before it entered cherry-picking mode. The first change 
to qtbase 5.6 was uploaded to Gerrit on August 11th 2015. The last merge that I 
can see away from 5.6 was on November 25th 2016. That's ~16 months of merging.


Short of other options, I think the method of using git merge is the option 
that's least painful for a long lived qt 6 branch.


Simon


From: Ville Voutilainen 
Sent: Thursday, January 24, 2019 10:29:13 PM
To: Simon Hausmann
Cc: Jedrzej Nowacki; development@qt-project.org
Subject: Re: [Development] Proposal: New branch model

On Thu, 24 Jan 2019 at 20:26, Simon Hausmann  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.

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@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Lars Knoll]

> On 24 Jan 2019, at 22:29, Ville Voutilainen  
> wrote:
> 
> On Thu, 24 Jan 2019 at 20:26, Simon Hausmann  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@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Ville Voutilainen]

On Thu, 24 Jan 2019 at 20:26, Simon Hausmann  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.

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@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Sergio Ahumada]

On 24.01.19 14:10, Edward Welbourne wrote:


Automated cherry-picking implies various complications that we haven't
fully explored; whereas merges have some well-established reliable
properties that avoid many of those complications.  Engineers prefer
what's known, from experience, to work over things that sound like they
might.  OTOH, as Ville points out, other projects do use cherry-picking;
so perhaps we need more information from such projects,



I have seen this implemented, similar to what Jedrek proposed, but the 
decision where to cherry pick is in JIRA, not via git annotations/marks.


This requires the Release Manager to keep an eye on which changes have 
not being propagated to all branches, though.


fully automated process, the fix is pushed to the oldest branch (5.12) 
and then propagated to newer versions (5.13, dev, etc). Change is 
automatically cherry-picked, updated the commit message, uploaded to 
gerrit, automatic Code-Review+2, automatic stage, automatically merged 
if CI passes.


propagation rate failure is around 20% of, mostly due to:
- merge conflicts (will happen, for sure)
-- genuine merge conflicts
-- change was already cherry-picked manually
-- dependencies missing
- ci failures
-- mostly due to infrastructure issues
-- ci does not know how to handle dependencies

advantages:
- when it works, everybody is happy
- pass rate is very high (around 80%)
- one can run git-cherry-pick -n and add additional info in the commit 
message
- can be tuned up to exclude some changes from being propagated (the 
bot, not git-cherry-pick itself)


disadvantages:
- most developers don't know how to handle the propagation failures
-- I already moved on and am working on something else, do you want me 
to switch to '5.19' to fix a change I did in '5.12' ? oh, and it failed 
in '5.18' as well? why don't you do merges instead and leave alone? 
[true story :-)]

- change can pass the CI and found to be problematic later on
-- oh, I need to fix my change in 5 branches now? [Gerrit 2.14 has a 
cherry-pick button in the UI now, so this is not a problem with that 
version]

- automated cherry-pick process/bot/script has to be maintained
-- one change not merged might lead to lots of changes to fail with 
merge conflicts, staying open in gerrit forever
-- hey, can you add intelligence to the bot so it know how to merge the 
open changes once the dependency is merged?
-- hey, can you add intelligence to the bot so it can cherry-pick them 
in the right order?)
- yes, git-cherry-pick does weird things. I have seen it cherry-picking 
the same change twice without problems (same line twice in the file, I 
think I was an include guard that compiled but behaved weirdly, or similar)


my 2€
--
Sergio Ahumada
sahum...@texla.cl


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Simon Hausmann]

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.

Simon

> On 24. Jan 2019, at 15:28, Jedrzej Nowacki  wrote:
> 
> Dnia środa, 23 stycznia 2019 23:05:17 CET Allan Sandfeld Jensen pisze:
>> More than that. Once you have had cherry-pick only for a while git will be
>> unable to find useful common ancestors for the changes, and will be unable
>> to do smart three-way merging of cherry-picks, increasing the number of
>> conflicts that needs to be resolved manually while decreasing the useful
>> information git can give you (no more useful three-way diff).
>> 
>> 'Allan
> 
> Good point, that is a risk. Question is how big it is. Does it really affect 
> us, as old branches over time should be modified less and less. Are there 
> tooling like git rerere able to help us?
> 
> Cheers,
>  Jędrek
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia czwartek, 24 stycznia 2019 13:33:28 CET Allan Sandfeld Jensen pisze:
> On Donnerstag, 24. Januar 2019 13:27:41 CET Jedrzej Nowacki wrote:
> > Dnia środa, 23 stycznia 2019 22:04:16 CET Allan Sandfeld Jensen pisze:
> > > On Mittwoch, 23. Januar 2019 16:51:10 CET Jedrzej Nowacki wrote:
> > > >   Proposal in short: let's use cherry-pick mode everywhere.
> > > >   
> > > >   All(**) changes would go to dev. From which they would be
> > > >   automatically
> > > > 
> > > > cherry-picked by a bot to other branches. The decision to which branch
> > > > cherry-
> > >  
> > >  pick, would be taken based on a tag in the commit message. We
> > >  
> > > > could add a footer that marks the change risk level as in quip-5
> > > > (http://quips-qt-io.herokuapp.com/quip-0005.html), so for example
> > > > "dev",
> > > > "stable", "LTS". By default everything would be cherry-picked to qt6
> > > > branch
> > > > unless "no-future" tag would be given. Of course we can bike-shed
> > > > about
> > > > the
> > > > tag names.
> > > 
> > > I don't see any advantage to this what so ever. The same amount of work
> > > and
> 
>  refactoring needs to be done, all you have done is made development
> 
> > > more prone to human error, and fixes less likely to reach their intended
> > > target, and made getting point releases out on time harder as they need
> > > to go through more steps before they have all their patches in.
> > > 
> > > 'Allan
> > 
> > It is hard to answer this because you have forgotten to write why you
> > think
> 
>  that development would be more error prone or fixes less likely to reach
> 
> > the destination or more steps would be involved in releasing. So I will
> > try
> > shooting in the dark :-)
> > 
> > The current merging strategy involves couple of people, one merge master
> > and a
> 
>  random reviewer that looks at conflicts if there are any. Usually it is
> 
> > not even close to quality level we have for single patches in which we
> > have
> > more reviewers and gerrit shows the real diff. In practice we assume that
> > no conflicts == good merge.
> > 
> > Fixes are less likely to hit target branches, true, but only if nobody
> > cares.
> 
>  Mark that a fix can magically disappear during broken mere, nobody
> 
> > will see it. The proposed solution allows at least track such cases.
> > 
> > Releases branches already use cherry-pick mode so from that perspective
> > there
> 
>  is no big changes, the only one is the origin branch from which the
> 
> > cherry- pick should happen.
> 
> Yeah, this was no the best of comments on the issue. But I believe I wrote
> my objections elsewhere:
> - Cherry-picks are more error prone in git than merges and requires manual
> intervention more frequently

Yes, they are in some ways, I think I managed to not hide them in the 
proposal. I believe that the load distribution, the fact that more people can 
handle issues, reduction in bus factor, ability to solve problems in parallel 
with a significantly smaller context/scope and transparency of the process 
overweight the risks.

In addition we may write tooling, that helps us to detect problems, like for 
example gerrit change hanging in a limbo for too long, because all of the data 
would be there. 

> - Even if we accept the always and instantly cherry-pick model, there is no
> reason to push to dev, continuing to push to the same branches as now could
> achieve all the same things with less room for error (because where it is
> supposed to be merged to is both implicit and unambigious)

I mentioned that before. Cherry-picking from stable to dev means that in case 
of an error we have a regression. In my opinion it is worse, then accidentally 
not having a fix for something that was broken forever in an older branch.

> - By having all commits go to the same branch you make that branch
> overloaded, and will break our CI even more than it already is.

I will answer that in other part of thread, as I believe it deserve a subtopic 
on it's own.

> - I don't see making it harder to fix bugs in the stable branch as a
> benefit.

Why harder? Conflicts rate is more or less the same, they will be just resolved 
by a different person. So I wouldn't call it harder just the maintenance cost 
would be more visible / moved to the author.

Cheers, 
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia czwartek, 24 stycznia 2019 14:23:21 CET Kari Oikarinen pisze:
> We're also using cherry-picking ourselves in LTS branches. At least older
> ones,
 5.12 is not at that mode yet. As far as I know it has been working
> well. 
> Since the problems with cherry-picking come up as the changes pile up and
> concurrent development happens, those are largely avoided in the older
> branches.
 
> A less ambitious change to our current process could be moving branches
> into
 cherry-picking mode earlier. That would limit the count of currently
> active branches that we need to merge between. Of course the effects of
> such a change would be much smaller also. But just to mention it because I
> don't think anyone has mentioned it yet.
> 
> -- 

Good point, we could move branches to cherry-pick mode earlier. So for example 
if we have qt6, dev and stable (whatever the number is) we would have "only" 
two merges from stable to qt6. Or we could keep merges from dev to qt6 for a 
little longer. Personally I would go all for cherry-pick mode instead to 
simplify the model, but I agree that it is still better then what we have now.

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Edward Welbourne]

On Wednesday, 23 January 2019 11:01:53 PST Volker Hilsheimer wrote:
 I think that’s fine. What’s much worse is having a fix in 5.12 and
 not knowing how to deal with the merge conflicts into dev. That
 means dev might regress, unless whoever authored the change is
 willing to spend time on making it work. In the end, if
 contributors can’t own their changes for all various branches of
 Qt, then I much prefer for them to own the changes at least for
 dev. And with Qt 6, this will become a much bigger problem.

Thiago Macieira (23 January 2019 20:10)
>>> The problem is I can turn this around and say that we introduce
>>> regressions into the older branches due to an improper cherry-pick
>>> that didn't conflict.

Dnia środa, 23 stycznia 2019 21:47:16 CET Edward Welbourne pisze:
>> and *that* is a concern that does bother me.
>> Of course, it's got to pass integration, as well as not conflict, but
>> that doesn't guarantee it hasn't broken something.

Jedrzej Nowacki (24 January 2019 15:11)
> Of course, but it is not a regression to the current system, we have
> the problem currently, right?

Only for LTS branches, to which relatively few changes get picked.

> We can introduce a regression in a release branch

Just to be clear: while some cherry-picks do happen to release branches,
that is not their normal model.  Changes for an imminent release should
be sent to its release branch in the first instance.  The only thing
that's different there is that *staging* gets to be reserved to the
release team.

The only branches to which we currently cherry-pick by default are the
LTS ones.  Here the problem Thiago points out is *a bit* mitigated by
attentive review and the fact that it's a past branch we know well and
reviewers likely have some clue about what changes have happened since
that might not mix well with the change being cherry-picked; but this
only mitigates the problem a bit (we forget details) and I have my
doubts about how well that would work if we had more past branches to
remember that much about (I routinely get confused about which branch
first got a given change, even of mine, much less by anyone else), so
I'm not sure the mitigation would scale to twice as many destination
branches for cherry-picking.

> by merging and cherry-picking without conflicts. On the other hand
> logic that doesn't apply cleanly has a higher chances of introducing
> bugs and therefore higher chance of causing release problems.

well, breakage on the next LTS branch, that'll show up in its next
release, since (non-LTS) release branches don't get cherry-picks (much).

> These changes are more visible in gerrit as opposite to somehow opaque
> merges. So in my opinion it is an improvement.

That doesn't help the folk doing the LTS release, if the cherry-pick
went in without conflict and without any integration test failing.
The first they know about it is RTA or, worse, later.
So the change is more visible, yes, but how does that help anyone ?

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia środa, 23 stycznia 2019 23:05:17 CET Allan Sandfeld Jensen pisze:
> More than that. Once you have had cherry-pick only for a while git will be
> unable to find useful common ancestors for the changes, and will be unable
> to do smart three-way merging of cherry-picks, increasing the number of
> conflicts that needs to be resolved manually while decreasing the useful
> information git can give you (no more useful three-way diff).
> 
> 'Allan

Good point, that is a risk. Question is how big it is. Does it really affect 
us, as old branches over time should be modified less and less. Are there 
tooling like git rerere able to help us?

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model (part: new contributors)

[Ville Voutilainen]

On Thu, 24 Jan 2019 at 16:14, Konstantin Tokarev  wrote:
>
>
>
> 24.01.2019, 17:09, "Ville Voutilainen" :
> > With the proposed model I push into trunk like in every other project.
>
> Why every other? Quite a few projects have different policies, e.g. in
> some of them master is always in more-or-less ready for release state
> and new changes go to staging branch like "dev" or "next"

Well, sure, my comment is anecdotal. Then there are frozen-trunk
project, likes GCC, where I need
to sit on my adventurous patches while trunk is about to branch. In
such projects, I still push into
trunk first, always. In Qt, I need to spend time thinking where to
push, need to look at commit policy,
and verify my understanding by asking for help. Which is also
anecdotal, maybe it's just me.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

On 24.1.2019 16.15, Edward Welbourne wrote:
> Kari Oikarinen (24 January 2019 15:02)
>> The rest of the paragraph talks about a situation where we will have two 
>> stable
>> branches alive at the same time. Typically we don't, because once 5.x+1 is
>> created, 5.x is closed.
> 
> Not quite: once 5.x+1 is *released*, 5.x (if not LTS) is closed
> (unless we have a pressing reason to release another 5.x.y).
> So, in the interval between 5.x+1 branching and releasing,
> we have three branches.

Right, so typically we indeed have two stable branches open. Thanks for 
correcting me.

> 
>> But 5.12 is an LTS version, so it will still stay open.
> 
> Indeed.
> 
>> But at what point (under current process) would be switch it to cherry-pick 
>> only
>> mode? I don't remember when it happened for 5.9. It could be when 5.13 is
>> created and then there would be no release blocked by waiting for a merge.
> 
> We switch to cherry-picking into 5.12 when 5.14 is created.
> See QUIP-5,
> * https://quips-qt-io.herokuapp.com/quip-0005.html
> 
> So creation of 5.14 switches our merge pattern from 5.12->5.13->dev
> to 5.13->5.14->dev and the 5.14 release (probably) closes 5.13.
> Again, we could of course change that.

Yes, but I was attempting to describe the current approach and messed it up.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Konstantin Tokarev]

24.01.2019, 17:13, "Jedrzej Nowacki" :
> Dnia środa, 23 stycznia 2019 21:47:16 CET Edward Welbourne pisze:
>>  On Wednesday, 23 January 2019 11:01:53 PST Volker Hilsheimer wrote:
>>  >> I think that’s fine. What’s much worse is having a fix in 5.12 and not
>>  >> knowing how to deal with the merge conflicts into dev. That means dev
>>  >> might
>>  >> regress, unless whoever authored the change is willing to spend time on
>>  >> making it work. In the end, if contributors can’t own their changes for
>>  >> all
>>  >> various branches of Qt, then I much prefer for them to own the changes at
>>  >> least for dev. And with Qt 6, this will become a much bigger problem.
>>
>>  Thiago Macieira (23 January 2019 20:10)
>>
>>  > The problem is I can turn this around and say that we introduce
>>  > regressions
>>  > into the older branches due to an improper cherry-pick that didn't
>>  > conflict.
>>  and *that* is a concern that does bother me.
>>  Of course, it's got to pass integration, as well as not conflict,
>>  but that doesn't guarantee it hasn't broken something.
>
> Of course, but it is not a regression to the current system, we have the
> problem currently, right? We can introduce a regression in a release branch by
> merging and cherry-picking without conflicts. On the other hand logic that
> doesn't apply cleanly has a higher chances of introducing bugs and therefore
> higher chance of causing release problems. These changes are more visible in
> gerrit as opposite to somehow opaque merges. So in my opinion it is an
> improvement.

However, regression in stable branch costs more, as in worst case it can result 
in
brown paper bug being released

>
> Cheers,
>   Jędrek
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Edward Welbourne]

Kari Oikarinen (24 January 2019 15:02)
> The rest of the paragraph talks about a situation where we will have two 
> stable
> branches alive at the same time. Typically we don't, because once 5.x+1 is
> created, 5.x is closed.

Not quite: once 5.x+1 is *released*, 5.x (if not LTS) is closed
(unless we have a pressing reason to release another 5.x.y).
So, in the interval between 5.x+1 branching and releasing,
we have three branches.

> But 5.12 is an LTS version, so it will still stay open.

Indeed.

> But at what point (under current process) would be switch it to cherry-pick 
> only
> mode? I don't remember when it happened for 5.9. It could be when 5.13 is
> created and then there would be no release blocked by waiting for a merge.

We switch to cherry-picking into 5.12 when 5.14 is created.
See QUIP-5,
* https://quips-qt-io.herokuapp.com/quip-0005.html

So creation of 5.14 switches our merge pattern from 5.12->5.13->dev
to 5.13->5.14->dev and the 5.14 release (probably) closes 5.13.
Again, we could of course change that.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Ville Voutilainen]

On Thu, 24 Jan 2019 at 15:39, Shawn Rutledge  wrote:
>
>
>
> > On 24 Jan 2019, at 14:15, Jedrzej Nowacki  wrote:
> >
> > Typical use case I have with bug fixing in dev is when I develop a feature 
> > and
> > I see let's say a memory leak in the code that I'm modifying or somewhere
> > around. With the merge model I have four options now:
> > 1. Pretend that I haven't seen it
> > 2. Make a fix in LTS and develop my feature separately, counting on the 
> > merge
> > master to resolve conflicts
> > 3. Do the fix only in dev
> > 4. Make a fix in LTS and wait for all merges before I continue with the 
> > feature
> > If it is a memory leak then it is not as bad as memory corruption and 
> > crashes,
> > as at that point I can not use approach 2. Option 1 and 3 are not great from
> > QA perspective. Option 4 is slow and kills motivation for development.
>
> 5. Ask Liang to do a merge ASAP, as soon as the LTS fix is integrated
>
> 6. Do the merge yourself on dev, push it, add reviewers, and in the meantime, 
> develop your feature on top (but so far we have a cultural limitation on who 
> is allowed to do this)
>
> 7. Cherry-pick the fix patch on dev so that you can keep working.  After that:
> 7a. Periodically run git pull —rebase locally until the rebase pulls in the 
> merged fix, and your new changes are now on the tip; by then, nobody can see 
> that you did the cherry-pick; or,
> 7b. Push both patches, with the cherry-picked fix marked WIP and with a note 
> that it’s a temporary cherry-pick, so that nobody will try to review or 
> integrate it (or write redundant comments reminding you that you shouldn’t do 
> that).  This way you can get your new work reviewed: you just can’t stage it 
> until the merge is done (and then you can abandon the cherry-picked fix).

Right. As opposed to

in-backporting-cherry-pick-mode) fix the bug in dev, backport to older
branches, life on all branches goes on with the fix applied

Having seven options is not necessarily better.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model (part: new contributors)

[Konstantin Tokarev]

24.01.2019, 17:09, "Ville Voutilainen" :
> With the proposed model I push into trunk like in every other project.

Why every other? Quite a few projects have different policies, e.g. in
some of them master is always in more-or-less ready for release state
and new changes go to staging branch like "dev" or "next"

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model (part: new contributors)

[Jedrzej Nowacki]

Dnia środa, 23 stycznia 2019 18:09:31 CET Alex Blasche pisze:
> > - simpler for new contributors, always push to dev
> 
> Really? Me being the new guy wanting to fix a bug in 5.12 need to magically
> know that I have to push to dev and know about a magic cherry-pick logic
> and a magic tag in the commit log. Right now I need to know I want to fix
> in 512 and push to it. Also the current model does not bother the new guy
> with myriads of potentially following cherry-picks which may require a
> larger commitment than he is willing to give. 

Really, at least that is my latest experience, when I contributed a fix to 
python standard library. I was trying to understand the branching model just 
to read that I should not bother and push stuff to master, there it was the 
reviewer responsibility to cherry-pick the change to other branches based on 
the content. I have to admit that I was impressed how easy is to make the first 
time contribution to the project. In our case, gerrit allows you to change 
commit message online in the browser, that makes reviewing / re-targeting  
task easier and less prone to errors (case of accidental re-push to a wrong 
branch after bot moving it). You are assuming that the contributor knows that 
the fix has to be and can be in 5.12. Well, that may be the case, some will 
have no clue and be fine with any future release. 

If a new contributor pushes to a wrong branch sanity bot would warn and allow 
you to move it to dev.

> The entire bot logic section below is another non-implicit logic.

What do you mean? As you do not target 5.X.Z, I would call it quite implicit 
:-).

Cheers,
  Jedrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Ville Voutilainen]

On Thu, 24 Jan 2019 at 15:47, Edward Welbourne  wrote:
>
> Allan Sandfeld Jensen (24 January 2019 14:35)
> > We can't integrate multiple changes to the same branch in parellel.
>
> I was under the impression that was exactly what we do.
>
> When I press Stage, my change gets cherry-picked to a little branch that
> gerrit is building, along with (i.e. in parallel with) various other
> changes staged around the same time.  When Coin next has its hands free,
> it starts a new integration of that staging branch (and a fresh staging
> branch is started).  If the integration fails, the message at the end of
> the comment on my review tells me the list of other commits that were in
> the same integration branch.
>
> Or have I misunderstood what you're saying ?

That's not "in parallel". :)
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

On 24.1.2019 15.15, Jedrzej Nowacki wrote:
> Last, but not least. The release branches are already in cherry-pick mode, so
> again it is not different, amount of conflicts is the same, true one needs to
> solve them earlier,  but on the other hand you can prepare the conflict
> resolution in parallel, while waiting for the integration. In your example you
> picked an easy target, but try the same with 5.13 and case of a fix targeting
> LTS. With the current model you need one merge (5.12 -> 5.13) and then one
> cherry-pick (5.13 -> 5.13.x). Of course you could cherry-pick from LTS
> directly to the release branch, but then you are acknowledge that merges are
> hurting us in terms of release speed.

Our release branches aren't in cherry-pick mode. If you have a blocker fix for
5.12.1 right now, it should be submitted into 5.12.1. The changes will reach
5.12 by a merge that will be done later. Based on a quick look qtbase 5.12.1 had
only one cherry-pick since the downmerge, so cherry-picking into release
branches is an exception, not the rule.

The rest of the paragraph talks about a situation where we will have two stable
branches alive at the same time. Typically we don't, because once 5.x+1 is
created, 5.x is closed. But 5.12 is an LTS version, so it will still stay open.
But at what point (under current process) would be switch it to cherry-pick only
mode? I don't remember when it happened for 5.9. It could be when 5.13 is
created and then there would be no release blocked by waiting for a merge.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia środa, 23 stycznia 2019 21:47:16 CET Edward Welbourne pisze:
> On Wednesday, 23 January 2019 11:01:53 PST Volker Hilsheimer wrote:
> >> I think that’s fine. What’s much worse is having a fix in 5.12 and not
> >> knowing how to deal with the merge conflicts into dev. That means dev
> >> might
> >> regress, unless whoever authored the change is willing to spend time on
> >> making it work. In the end, if contributors can’t own their changes for
> >> all
> >> various branches of Qt, then I much prefer for them to own the changes at
> >> least for dev. And with Qt 6, this will become a much bigger problem.
> 
> Thiago Macieira (23 January 2019 20:10)
> 
> > The problem is I can turn this around and say that we introduce
> > regressions
> > into the older branches due to an improper cherry-pick that didn't
> > conflict.
> and *that* is a concern that does bother me.
> Of course, it's got to pass integration, as well as not conflict,
> but that doesn't guarantee it hasn't broken something.

Of course, but it is not a regression to the current system, we have the 
problem currently, right? We can introduce a regression in a release branch by 
merging and cherry-picking without conflicts. On the other hand logic that 
doesn't apply cleanly has a higher chances of introducing bugs and therefore 
higher chance of causing release problems. These changes are more visible in 
gerrit as opposite to somehow opaque merges. So in my opinion it is an 
improvement.

Cheers,
  Jędrek




___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model (part: new contributors)

[Ville Voutilainen]

On Thu, 24 Jan 2019 at 15:56, Jedrzej Nowacki  wrote:
>
> Dnia środa, 23 stycznia 2019 18:09:31 CET Alex Blasche pisze:
> > > - simpler for new contributors, always push to dev
> >
> > Really? Me being the new guy wanting to fix a bug in 5.12 need to magically
> > know that I have to push to dev and know about a magic cherry-pick logic
> > and a magic tag in the commit log. Right now I need to know I want to fix
> > in 512 and push to it. Also the current model does not bother the new guy
> > with myriads of potentially following cherry-picks which may require a
> > larger commitment than he is willing to give.
>
> Really, at least that is my latest experience, when I contributed a fix to
> python standard library. I was trying to understand the branching model just
> to read that I should not bother and push stuff to master, there it was the
> reviewer responsibility to cherry-pick the change to other branches based on
> the content. I have to admit that I was impressed how easy is to make the 
> first
> time contribution to the project. In our case, gerrit allows you to change
> commit message online in the browser, that makes reviewing / re-targeting
> task easier and less prone to errors (case of accidental re-push to a wrong
> branch after bot moving it). You are assuming that the contributor knows that
> the fix has to be and can be in 5.12. Well, that may be the case, some will
> have no clue and be fine with any future release.

Well, me being a new guy wanting to fix a bug in 5.14 need to
magically know that I need
to push to 5.12 and then wait for a forward merge. With the proposed
model I push into
trunk like in every other project. As far as following cherry-picks
go, they don't necessarily
need to bother me, they could be done by other people, some called maintainers.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Edward Welbourne]

Allan Sandfeld Jensen (24 January 2019 14:35)
> We can't integrate multiple changes to the same branch in parellel.

I was under the impression that was exactly what we do.

When I press Stage, my change gets cherry-picked to a little branch that
gerrit is building, along with (i.e. in parallel with) various other
changes staged around the same time.  When Coin next has its hands free,
it starts a new integration of that staging branch (and a fresh staging
branch is started).  If the integration fails, the message at the end of
the comment on my review tells me the list of other commits that were in
the same integration branch.

Or have I misunderstood what you're saying ?

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Shawn Rutledge]

> On 24 Jan 2019, at 14:15, Jedrzej Nowacki  wrote:
> 
> Typical use case I have with bug fixing in dev is when I develop a feature 
> and 
> I see let's say a memory leak in the code that I'm modifying or somewhere 
> around. With the merge model I have four options now:
> 1. Pretend that I haven't seen it
> 2. Make a fix in LTS and develop my feature separately, counting on the merge 
> master to resolve conflicts
> 3. Do the fix only in dev
> 4. Make a fix in LTS and wait for all merges before I continue with the 
> feature
> If it is a memory leak then it is not as bad as memory corruption and 
> crashes, 
> as at that point I can not use approach 2. Option 1 and 3 are not great from 
> QA perspective. Option 4 is slow and kills motivation for development.

5. Ask Liang to do a merge ASAP, as soon as the LTS fix is integrated

6. Do the merge yourself on dev, push it, add reviewers, and in the meantime, 
develop your feature on top (but so far we have a cultural limitation on who is 
allowed to do this)

7. Cherry-pick the fix patch on dev so that you can keep working.  After that:
7a. Periodically run git pull —rebase locally until the rebase pulls in the 
merged fix, and your new changes are now on the tip; by then, nobody can see 
that you did the cherry-pick; or, 
7b. Push both patches, with the cherry-picked fix marked WIP and with a note 
that it’s a temporary cherry-pick, so that nobody will try to review or 
integrate it (or write redundant comments reminding you that you shouldn’t do 
that).  This way you can get your new work reviewed: you just can’t stage it 
until the merge is done (and then you can abandon the cherry-picked fix).

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Allan Sandfeld Jensen]

On Donnerstag, 24. Januar 2019 14:31:16 CET Jedrzej Nowacki wrote:
> Dnia czwartek, 24 stycznia 2019 10:24:57 CET Allan Sandfeld Jensen pisze:
> 
> > On Donnerstag, 24. Januar 2019 10:11:35 CET Volker Hilsheimer wrote:
> > 
> > > More people working and building against dev helps keep dev more stable
> > > (by
> > > virtue of discovering breakage sooner), and the proposal encourages
> > > more
> > > people to work on dev. That can be a good thing.
> > 
> > 
> > No,  it will overload the CI by having all integrations happen on the
> > same
> > branch, instead being able to integrate multiple branches at once.
> 
> 
> It will overload in what way? Yes, in total we would have more integrations.
> 
 If you look into the statistics (https://testresults.qt.io/grafana/d/
> 00024/telegraf-host-metrics) you can see that we have some free
> resources. In general we should not really cross load of 60, but most of
> the hosts are on significantly lower load. I would be more concerned about
> flakiness, as it means that we run more tests, but that is something that
> we need to fix no matter what.
> 
We can't integrate multiple changes to the same branch in parellel. So you 
can't start using more resources to speed things up. (9 women to have a child 
in 1 month) The only way to speed up CI integration is to be merging to 
different branches, that way we CAN have multiple integrations running in 
parallel.

'Allan


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia czwartek, 24 stycznia 2019 10:24:57 CET Allan Sandfeld Jensen pisze:
> On Donnerstag, 24. Januar 2019 10:11:35 CET Volker Hilsheimer wrote:
> > More people working and building against dev helps keep dev more stable
> > (by
> > virtue of discovering breakage sooner), and the proposal encourages more
> > people to work on dev. That can be a good thing.
> 
> No,  it will overload the CI by having all integrations happen on the same
> branch, instead being able to integrate multiple branches at once.

It will overload in what way? Yes, in total we would have more integrations. 
If you look into the statistics (https://testresults.qt.io/grafana/d/
00024/telegraf-host-metrics) you can see that we have some free resources. 
In general we should not really cross load of 60, but most of the hosts are on 
significantly lower load. I would be more concerned about flakiness, as it 
means 
that we run more tests, but that is something that we need to fix no matter 
what.

> > Either way, nothing in the proposal prevents us from developing and push a
> > fix for 5.12, and then develop a different fix for dev that we don’t
> > cherry
> > pick into 5.12 or other stable branches. This should be an exception, used
> > in urgent situations where indeed we can’t wait. For those cases, there’s
> > no merge conflict in the first place in the new model (because there’s no
> > merge).
> 
> It is still doing merging the wrong way for no good reason. Even if cherry-
> picking itself wasnt a bad idea. You could just as well commit to the stable
> branch first and then cherry-pick it to the other branches. That way there
> would be no need for cryptic annotations, the branches to pick to would be
> implicit from where the patch first landed. Or even better, you could
> perform a merge to dev on every single commit to the stable branch, or even
> better, only create a merge if there are conflicts, so we don't overload
> the CI on dev.
> 
> 'Allan

If you cherry-pick the opposite way, the risk of regression is; higher, 
because of one time contributions (I'm using 5.9 I do not care about other 
releases, so I will not solve the merge conflicts or baby sit the changes) or 
because of lack of interest (oh, that is simply re-write I will not do it) or 
because just a mistake (oh it is still in my gerrit dashboard). In my opinion 
regressions are much worse then, a missing fix in an older branch.

Cheers,
  Jędrek



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Shawn Rutledge]

> On 24 Jan 2019, at 14:10, Edward Welbourne  wrote:
> 
> Dnia czwartek, 24 stycznia 2019 09:08:29 CET Liang Qi pisze:
>>> My concern is about "cherry-pick" a series of changes for a big
>>> feature, especially during the period to have "dev" branches for both
>>> 5 and 6. I don't have solution for this issue yet.
> 
> Jedrzej Nowacki (24 January 2019 11:53)
>> My assumption is that bot would cherry-pick them in the same order in
>> which patches got integrated to dev. That way we could reduce amount
>> of issues. Of course if the first patch from a series causes conflicts
>> then all other would also be in conflict.
> 
> Well, the *initial* cherry-pick-and-send-to-Coin can be made to happen
> in the same order; but after that, any that didn't get through on the
> first pass are going to be apparently-unrelated changes waiting to go
> into the destination branch.  The script might be able to look at the
> upstream dev versions of its cherry-picks and reproduce the dependencies
> among them, but that's going to get tricky when some of those upstream
> changes got integrated out of order (because some of them were merely
> later in the branch, without a strict dependence on those earlier) or
> some of them succeed on the first pass while others, before and after
> them on the original branch, fail.  Either you'll end up losing some
> dependency relations or you risk having things on my branch depend on
> other folks' unrelated changes that were just upstream of my branch,
> that haven't yet made it through cherry-picking.  This isn't fatal, as
> the developer taking care of the post-failure fix-up and/or retries can
> stage despite a dependency missing, but it'll cause some pain at times.

Either way it can fail though: if the bot tries too hard to keep the patches in 
order, we’ll all waste time whenever a lot of patches “depend” on one that is 
failing to be cherry-picked to a release branch.  (So then isn’t it similar to 
merging change sets from feature branches, in that the whole branch is an 
all-or-nothing deal?  That’s what I dislike about how GitHub does it.)  But if 
we don’t keep them in order, it will be the same as now when trying to stage 
any given patch: individual patches will need rebasing sometimes, and that’s 
also extra hassle.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

On 24.1.2019 15.10, Edward Welbourne wrote:
> Dnia czwartek, 24 stycznia 2019 09:08:29 CET Liang Qi pisze:
>>> My concern is about "cherry-pick" a series of changes for a big
>>> feature, especially during the period to have "dev" branches for both
>>> 5 and 6. I don't have solution for this issue yet.
> 
> Jedrzej Nowacki (24 January 2019 11:53)
>> My assumption is that bot would cherry-pick them in the same order in
>> which patches got integrated to dev. That way we could reduce amount
>> of issues. Of course if the first patch from a series causes conflicts
>> then all other would also be in conflict.
> 
> Well, the *initial* cherry-pick-and-send-to-Coin can be made to happen
> in the same order; but after that, any that didn't get through on the
> first pass are going to be apparently-unrelated changes waiting to go
> into the destination branch.  The script might be able to look at the
> upstream dev versions of its cherry-picks and reproduce the dependencies
> among them, but that's going to get tricky when some of those upstream
> changes got integrated out of order (because some of them were merely
> later in the branch, without a strict dependence on those earlier) or
> some of them succeed on the first pass while others, before and after
> them on the original branch, fail.  Either you'll end up losing some
> dependency relations or you risk having things on my branch depend on
> other folks' unrelated changes that were just upstream of my branch,
> that haven't yet made it through cherry-picking.  This isn't fatal, as
> the developer taking care of the post-failure fix-up and/or retries can
> stage despite a dependency missing, but it'll cause some pain at times.
> 
> There are also potential problems where I push to dev a fix for some
> issue, followed by a change that undoes a kludge-around whose root cause
> is the issue I've just fixed, but which was put there to fix some
> seemingly unrelated issue.  Even if the first fix's cherry-pick hits a
> conflict or fails to integrate, it's entirely possible that the removal
> of the kludge-around gets through on the first pass; and that could be a
> problem.  With luck there's a test for what it kludged round, that'll
> prevent it integrating; but, if there isn't, that issue resurfaces in
> the target branch until the real fix's cherry-pick lands.
> 
> Automated cherry-picking implies various complications that we haven't
> fully explored; whereas merges have some well-established reliable
> properties that avoid many of those complications.  Engineers prefer
> what's known, from experience, to work over things that sound like they
> might.  OTOH, as Ville points out, other projects do use cherry-picking;
> so perhaps we need more information from such projects,

We're also using cherry-picking ourselves in LTS branches. At least older ones,
5.12 is not at that mode yet. As far as I know it has been working well.

Since the problems with cherry-picking come up as the changes pile up and
concurrent development happens, those are largely avoided in the older branches.

A less ambitious change to our current process could be moving branches into
cherry-picking mode earlier. That would limit the count of currently active
branches that we need to merge between. Of course the effects of such a change
would be much smaller also. But just to mention it because I don't think anyone
has mentioned it yet.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia środa, 23 stycznia 2019 22:09:30 CET Allan Sandfeld Jensen pisze:
> On Mittwoch, 23. Januar 2019 21:42:35 CET Edward Welbourne wrote:
> > Jedrzej Nowacki wrote:
> > >>  Advantages:
> > >>  - no waiting for merges, a fix can be used right away after
> > >>  
> > >>integration
> > >>  
> > >>  - faster propagation of fixes targeting all branches, as there are
> > >>  
> > >>no merges of merges
> > 
> > Alex Blasche (23 January 2019 18:09)
> > 
> > > This is pure speculation because you potentially triple (or worse) the
> > > amount of individual patches requiring a merge in gerrit when you
> > > consider that you want to at least merge to 5.9, 512, dev and qt6. I
> > > don't see this prediction come true.
> > 
> > Well, as soon as it hits dev, the patch is cherry-picked to every branch
> > that its footer says it belongs in.  Those branches where all goes well
> > see it one integration later.  Each branch that has a conflict needs
> > that resolved before we get to that second integrtion.  Contrast this
> > with a 5.12 -> 5.13 -> dev chain of merges, where dev doesn't get the
> > change that landed in 5.12 (even if that change could land in dev
> > without conflict) until
> > 
> >  * there's been some delay between their change being accepted in 5.12
> >  
> >and the next merge-bot run
> >  
> >  * everyone who made change to 5.12 that conflicted on merging to 5.13
> >  
> >has advised Liang on how to resolve their conflicts
> >  
> >  * we've got the result through integration into 5.13
> >  * everyone who's made changes to 5.13 or (as possibly just amended in
> >  
> >merging) 5.12 that conflicts with anything in dev has again advised
> >how to resolve their conflicts
> >  
> >  * and we've got the result through a second integration, into dev.
> > 
> > When nothing but the change being considered has a conflict along
> > the way, that's twice as long; and any change to an upstream branch,
> > that does have a conflict, introduces delay for all the other changes
> > that landed in that branch, even if they don't have conflicts.  In the
> > middle of summer, when lots of folk are away on holiday, getting help
> > with resolving conflicts isn't easy - the folk who know those commits
> > won't be back for a month - and all changes, no matter how urgent, get
> > stuck behind any conflict we can't work out how to resolve.
> > 
> > So no, Jedrzej's claim is not *pure* speculation; it's at least quite a
> > lot adulterated with reasons to believe that many changes would, under
> > his scheme, propagate to all branches they're destined for sooner than
> > happens with our present scheme.
> 
> No, it is speculation, and it optimizing the least important case: bug-fixes
> in dev. Dev is the branch that can wait the longest to get a bug-fix, the
> stable branch is the branch that need it the most urgent. And fixing a bug
> in 5.12 now means you first fix it where you need it (5.12), then rewrite
> it for dev, then resolve the inevitable conflict back so it can be merged,
> all waiting for bots and release teams to stumple into the issues and
> delaying the next 5.12.x release.
> 

First, I do not agree that dev is less important. Dev is the base for all 
future releases. Even if a current release is broken in some way, the next one 
should not be. We can not focus on short term only.

Typical use case I have with bug fixing in dev is when I develop a feature and 
I see let's say a memory leak in the code that I'm modifying or somewhere 
around. With the merge model I have four options now:
1. Pretend that I haven't seen it
2. Make a fix in LTS and develop my feature separately, counting on the merge 
master to resolve conflicts
3. Do the fix only in dev
4. Make a fix in LTS and wait for all merges before I continue with the feature
If it is a memory leak then it is not as bad as memory corruption and crashes, 
as at that point I can not use approach 2. Option 1 and 3 are not great from 
QA perspective. Option 4 is slow and kills motivation for development.

Last, but not least. The release branches are already in cherry-pick mode, so 
again it is not different, amount of conflicts is the same, true one needs to 
solve them earlier,  but on the other hand you can prepare the conflict 
resolution in parallel, while waiting for the integration. In your example you 
picked an easy target, but try the same with 5.13 and case of a fix targeting 
LTS. With the current model you need one merge (5.12 -> 5.13) and then one 
cherry-pick (5.13 -> 5.13.x). Of course you could cherry-pick from LTS 
directly to the release branch, but then you are acknowledge that merges are 
hurting us in terms of release speed. 

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Edward Welbourne]

Dnia czwartek, 24 stycznia 2019 09:08:29 CET Liang Qi pisze:
>> My concern is about "cherry-pick" a series of changes for a big
>> feature, especially during the period to have "dev" branches for both
>> 5 and 6. I don't have solution for this issue yet.

Jedrzej Nowacki (24 January 2019 11:53)
> My assumption is that bot would cherry-pick them in the same order in
> which patches got integrated to dev. That way we could reduce amount
> of issues. Of course if the first patch from a series causes conflicts
> then all other would also be in conflict.

Well, the *initial* cherry-pick-and-send-to-Coin can be made to happen
in the same order; but after that, any that didn't get through on the
first pass are going to be apparently-unrelated changes waiting to go
into the destination branch.  The script might be able to look at the
upstream dev versions of its cherry-picks and reproduce the dependencies
among them, but that's going to get tricky when some of those upstream
changes got integrated out of order (because some of them were merely
later in the branch, without a strict dependence on those earlier) or
some of them succeed on the first pass while others, before and after
them on the original branch, fail.  Either you'll end up losing some
dependency relations or you risk having things on my branch depend on
other folks' unrelated changes that were just upstream of my branch,
that haven't yet made it through cherry-picking.  This isn't fatal, as
the developer taking care of the post-failure fix-up and/or retries can
stage despite a dependency missing, but it'll cause some pain at times.

There are also potential problems where I push to dev a fix for some
issue, followed by a change that undoes a kludge-around whose root cause
is the issue I've just fixed, but which was put there to fix some
seemingly unrelated issue.  Even if the first fix's cherry-pick hits a
conflict or fails to integrate, it's entirely possible that the removal
of the kludge-around gets through on the first pass; and that could be a
problem.  With luck there's a test for what it kludged round, that'll
prevent it integrating; but, if there isn't, that issue resurfaces in
the target branch until the real fix's cherry-pick lands.

Automated cherry-picking implies various complications that we haven't
fully explored; whereas merges have some well-established reliable
properties that avoid many of those complications.  Engineers prefer
what's known, from experience, to work over things that sound like they
might.  OTOH, as Ville points out, other projects do use cherry-picking;
so perhaps we need more information from such projects,

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Allan Sandfeld Jensen]

On Donnerstag, 24. Januar 2019 13:27:41 CET Jedrzej Nowacki wrote:
> Dnia środa, 23 stycznia 2019 22:04:16 CET Allan Sandfeld Jensen pisze:
> 
> > On Mittwoch, 23. Januar 2019 16:51:10 CET Jedrzej Nowacki wrote:
> > 
> > >   Proposal in short: let's use cherry-pick mode everywhere.
> > >   
> > >   All(**) changes would go to dev. From which they would be
> > >   automatically
> > > 
> > > 
> > > cherry-picked by a bot to other branches. The decision to which branch
> > > cherry-
> > 
> > 
> > 
> >  pick, would be taken based on a tag in the commit message. We
> > 
> > 
> > 
> > > could add a footer that marks the change risk level as in quip-5
> > > (http://quips-qt-io.herokuapp.com/quip-0005.html), so for example
> > > "dev",
> > > "stable", "LTS". By default everything would be cherry-picked to qt6
> > > branch
> > > unless "no-future" tag would be given. Of course we can bike-shed about
> > > the
> > > tag names.
> > 
> > 
> > I don't see any advantage to this what so ever. The same amount of work
> > and
 refactoring needs to be done, all you have done is made development
> > more prone to human error, and fixes less likely to reach their intended
> > target, and made getting point releases out on time harder as they need
> > to go through more steps before they have all their patches in.
> > 
> > 'Allan
> 
> 
> 
> It is hard to answer this because you have forgotten to write why you think
> 
 that development would be more error prone or fixes less likely to reach
> the destination or more steps would be involved in releasing. So I will try
> shooting in the dark :-)
> 
> The current merging strategy involves couple of people, one merge master and
> a 
 random reviewer that looks at conflicts if there are any. Usually it is
> not even close to quality level we have for single patches in which we have
> more reviewers and gerrit shows the real diff. In practice we assume that
> no conflicts == good merge.
> 
> Fixes are less likely to hit target branches, true, but only if nobody
> cares. 
 Mark that a fix can magically disappear during broken mere, nobody
> will see it. The proposed solution allows at least track such cases.
> 
> Releases branches already use cherry-pick mode so from that perspective
> there 
 is no big changes, the only one is the origin branch from which the
> cherry- pick should happen.
> 
Yeah, this was no the best of comments on the issue. But I believe I wrote my 
objections elsewhere:
- Cherry-picks are more error prone in git than merges and requires manual 
intervention more frequently
- Even if we accept the always and instantly cherry-pick model, there is no 
reason to push to dev, continuing to push to the same branches as now could 
achieve all the same things with less room for error (because where it is 
supposed to be merged to is both implicit and unambigious)
- By having all commits go to the same branch you make that branch overloaded, 
and will break our CI even more than it already is.
- I don't see making it harder to fix bugs in the stable branch as a benefit.

Best regards
'Allan




___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia środa, 23 stycznia 2019 22:04:16 CET Allan Sandfeld Jensen pisze:
> On Mittwoch, 23. Januar 2019 16:51:10 CET Jedrzej Nowacki wrote:
> >   Proposal in short: let's use cherry-pick mode everywhere.
> >   
> >   All(**) changes would go to dev. From which they would be automatically
> > 
> > cherry-picked by a bot to other branches. The decision to which branch
> > cherry-
> 
>  pick, would be taken based on a tag in the commit message. We
> 
> > could add a footer that marks the change risk level as in quip-5
> > (http://quips-qt-io.herokuapp.com/quip-0005.html), so for example "dev",
> > "stable", "LTS". By default everything would be cherry-picked to qt6
> > branch
> > unless "no-future" tag would be given. Of course we can bike-shed about
> > the
> > tag names.
> 
> I don't see any advantage to this what so ever. The same amount of work and
> refactoring needs to be done, all you have done is made development more
> prone to human error, and fixes less likely to reach their intended target,
> and made getting point releases out on time harder as they need to go
> through more steps before they have all their patches in.
> 
> 'Allan


It is hard to answer this because you have forgotten to write why you think 
that development would be more error prone or fixes less likely to reach the 
destination or more steps would be involved in releasing. So I will try 
shooting in the dark :-)

The current merging strategy involves couple of people, one merge master and a 
random reviewer that looks at conflicts if there are any. Usually it is not 
even close to quality level we have for single patches in which we have more 
reviewers and gerrit shows the real diff. In practice we assume that no 
conflicts == good merge.

Fixes are less likely to hit target branches, true, but only if nobody cares. 
Mark that a fix can magically disappear during broken mere, nobody will see it. 
The proposed solution allows at least track such cases.

Releases branches already use cherry-pick mode so from that perspective there 
is no big changes, the only one is the origin branch from which the cherry-
pick should happen.

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia czwartek, 24 stycznia 2019 11:24:41 CET Vitaly Fanaskov pisze:
> > Why not X instead?
> > --
> > 
> > - GitFlow, GitHub <= both are based on feature branches, that doesn't work
> > well with gerrit.
> 
> So, the only problem here is gerrit (aside from personal preferences and
> habits of course). The question is shouldn't we abandon gerrit as this
> tool doesn't feet with the needs well? Inventing new approaches is of
> course super cool... But not always necessary.
> 
> What's wrong with using, say, gitflow + gitlab + upsource? Upsource is
> optional, but it's the way better for code review than gerrit.

That is a completely different discussion. If we ever want to change the 
tooling we can re-consider branching model too.

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Aleksey Kontsevich]

Good point. Also thinking this way every time need to deal with Gerrit. Any 
chance to replace it to something more modern and convenient and less time 
wasting like GitLab, etc?

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich


24.01.2019, 12:28, "Vitaly Fanaskov" :
>> Why not X instead?
>> --
>>
>> - GitFlow, GitHub <= both are based on feature branches, that doesn't 
>> work
>>  well with gerrit.
>
> So, the only problem here is gerrit (aside from personal preferences and
> habits of course). The question is shouldn't we abandon gerrit as this
> tool doesn't feet with the needs well? Inventing new approaches is of
> course super cool... But not always necessary.
>
> What's wrong with using, say, gitflow + gitlab + upsource? Upsource is
> optional, but it's the way better for code review than gerrit.
>
> On 1/23/19 4:51 PM, Jedrzej Nowacki wrote:
>>  Hi,
>>
>> It is time to rethink our branch model. We are approaching Qt6 
>> development
>>  and I'm worried that what we have now, will simply not scale. As you know, 
>> our
>>  branch model is mainly(*) based on merging from stable up to development
>>  branches. In general, it is a very good model, which make sure that release
>>  branches are not getting obsolete too quickly, that most of the fixes are in
>>  the right places, that every commit is only once in the git history. It is a
>>  very clean model. It is also a very slow model, with a single point of
>>  failure.
>>
>> It is hard to maintain:
>> My impression is that the current model works great for a single release
>>  branch, but we have: 5.6 5.9 5.12 and soon we will have 5.13, that is 
>> without
>>  counting temporary patch level branches. Merging through them is hard, we
>>  already had to use "cherry-pick mode" in some places. When we add to the
>>  picture dev and qt6 branches, merging will be very, very hard. It is
>>  practically a full time job to update qt5 repository and coordinate all the
>>  merges now (thank you Liang!), shortly after qt6 branch opening amount of 
>> work
>>  will be much bigger.
>> It is slow:
>> The merges take time. We produce a lot of code, we have a lot of tests 
>> that
>>  needs to pass. Even single failure delays merge propagation by at least one
>>  day. If by bad luck, the merge contains some API incompatible changes an
>>  intermediate jump through Qt5 integration is required, that adds at least 3
>>  days of delay.
>>
>> --
>>
>> Proposal in short: let's use cherry-pick mode everywhere.
>>
>> All(**) changes would go to dev. From which they would be automatically
>>  cherry-picked by a bot to other branches. The decision to which branch 
>> cherry-
>>  pick, would be taken based on a tag in the commit message. We could add a
>>  footer that marks the change risk level as in quip-5 
>> (http://quips-qt-io.herokuapp.com/quip-0005.html), so for example "dev", 
>> "stable", "LTS". By
>>  default everything would be cherry-picked to qt6 branch unless "no-future" 
>> tag
>>  would be given. Of course we can bike-shed about the tag names.
>>
>> Advantages:
>> - no waiting for merges, a fix can be used right away after integration
>> - faster propagation of fixes targeting all branches, as there are no 
>> merges
>>  of merges
>> - simpler for new contributors, always push to dev
>> - in most cases a reviewer does no need to know what the current version
>>  number is
>> - conflict resolution is distributed and affects mostly the author of the
>>  change
>> - documents a change intent, which may be useful for people keeping own
>>  forks
>> - over time with increased amount of conflicts old branches, in natural 
>> way,
>>  stay untouched
>>
>> Disadvantages:
>> - git history would be a bit wilder, "git branch --contains" would not 
>> work
>> - commit messages in some branches would have kind of ugly footer as an
>>  effect of "cherry-pick -x"
>> - there is a chance, that some cherry-picked commits may be left 
>> forgotten
>>  in gerrit after a failed integration
>>
>> Bot details:
>>
>> The bot would listen only for changes in dev, in some unusual cases one
>>  could target an other branch directly, but bot would not trigger automatic
>>  cherry-pick(***). The bot would wait for a successful dev integration before
>>  creating cherry-picked changes. The bot would use cherry-pick -x to annotate
>>  the origin patch. After the cherry-pick creation, it would push it to 
>> gerrit,
>>  +2 and stage once. It would be up to the author to re-stage in case of
>>  flakiness. In case of a cherry-pick conflict it should push unresolved 
>> conflict
>>  to gerrit and add all reviewers and author to handle the issue.
>>
>>  The list below shows branch targets for automatic cherry-pick based on given
>>  tag.
>>
>>  dev (qt6)
>>  stable (qt6, 5.13)
>>  

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia czwartek, 24 stycznia 2019 09:08:29 CET Liang Qi pisze:
> My concern is about "cherry-pick" a series of changes for a big
> feature, especially during the period to have "dev" branches for both
> 5 and 6. I don't have solution for this issue yet.

My assumption is that bot would cherry-pick them in the same order in which 
patches got integrated to dev. That way we could reduce amount of issues. Of 
course if the first patch from a series causes conflicts then all other would 
also be in conflict.

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Ville Voutilainen]

On Wed, 23 Jan 2019 at 17:53, Jedrzej Nowacki  wrote:
>   Proposal in short: let's use cherry-pick mode everywhere.
>
>   All(**) changes would go to dev. From which they would be automatically
> cherry-picked by a bot to other branches. The decision to which branch cherry-
> pick, would be taken based on a tag in the commit message. We could add a
> footer that marks the change risk level as in quip-5 
> (http://quips-qt-io.herokuapp.com/quip-0005.html), so for example "dev", 
> "stable", "LTS". By
> default everything would be cherry-picked to qt6 branch unless "no-future" tag
> would be given. Of course we can bike-shed about the tag names.
>
>   Advantages:
>   - no waiting for merges, a fix can be used right away after integration
>   - faster propagation of fixes targeting all branches, as there are no merges
> of merges
>   - simpler for new contributors, always push to dev
>   - in most cases a reviewer does no need to know what the current version
> number is
>   - conflict resolution is distributed and affects mostly the author of the
> change
>   - documents a change intent, which may be useful for people keeping own
> forks
>   - over time with increased amount of conflicts old branches, in natural way,
> stay untouched
>
>   Disadvantages:
>   - git history would be a bit wilder, "git branch --contains" would not work
>   - commit messages in some branches would have kind of ugly footer as an
> effect of "cherry-pick -x"
>   - there is a chance, that some cherry-picked commits may be left forgotten
> in gerrit after a failed integration

+1 Strongly in Favor of this branching model. I use it in other
projects like GCC, I understand how it works, my
fixes land instantly on branches instead of waiting for a dedicated
person responsible for a merge to do it,
I never run into a situation where I fix a compilation problem in
5.12, someone else fixes it in 5.11, we all scratch
our heads about why we're duplicating work and also scratch our heads
how to resolve the merge conflict.
I can answer the questions about whether my fix will or will not land
in other branches and when, and I can make
sure it does land on the right branches because I can do those
cherry-picks myself, and I will, because I never
expect a magical merge to do it for me.

I consider this proposal a proposal to make our branching model
normal, regular, and unsurprising.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Edward Welbourne]

On 23.1.2019 17.51, Jedrzej Nowacki wrote:
>>Can we use annotate instead of cherry-pick -x?
>>--
>>
>>No, but we should use it in addition. Annotations are mutable,
>> therefore are not 100% trust worthy. If we have both, we could
>> validate annotations against commit message, sadly it would not
>> protect against annotation removal.

Kari Oikarinen (24 January 2019 11:37)
> What are these annotations? I tried to google them but only found
> documentation for git-annotate, which is just git-blame with a
> different output format.

They're actually called git "notes" (or "object notes");
see man git-notes.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia środa, 23 stycznia 2019 17:37:57 CET Konstantin Tokarev pisze:
> Note that backporting changes from dev should also be a full-time job for
> someone, otherwise amount of fixes going to stable branches will likely
> drop

Yes, depending who you ask it is good or bad. It means that only fixes that 
someone really cares about are really integrated to the stable branches. If 
somebody cares about a fix it means that it is more important. More over 
cherry-pick mode distributes the load of conflict resolution.

> >   - there is a chance, that some cherry-picked commits may be left
> > forgotten in gerrit after a failed integration
> 
> Or not submitted at all because of failed cherry-pick. Also, notorious
> property of cherry-pick strategy is explosion of conflicts: if there is a
> patch series modifying some code, and first of them requires adjustment to
> resolve conflict, it's likely that all fol
> lowing patches will have
> conflicts as well in the same places.

Assumption is that a bot would do the cherry-picking for you. If a cherry-pick 
cause conflicts, then the bot would push unresolved conflict to gerrit. So no, 
all changes would be in gerrit. Some may be to hard to resolve or one would 
lack a motivation. Again, main point is that it is up to author to resolve the 
conflicts.

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jedrzej Nowacki]

Dnia środa, 23 stycznia 2019 18:49:46 CET Thiago Macieira pisze:
> On Wednesday, 23 January 2019 08:37:57 PST Konstantin Tokarev wrote:
> > >   Disadvantages:
> > >   - git history would be a bit wilder, "git branch --contains" would not
> > >   work
> > >   - commit messages in some branches would have kind of ugly footer as
> > >   an
> > > 
> > > effect of "cherry-pick -x"
> > 
> > Gerrit's Change-Id can be used to track presence of patch in branches of
> > interest
> 
> Yes, but not as easily, since the git branch --contains and git tag
> --contains are pure DAG operations. The search you're talking about is a
> text search (usually implemented by a regexp search) on the commit message,
> with no DAG boundaries. You have to scan all valid branches for a given
> string.
> 
> And then you still have to run git branch --contains on each entry you found
> to figure out which branches contain those commits.
> 
> So this is scriptable. It's going to be something like 100x slower than
> today, but it should still finish within 10 seconds, even on slow machines.

As we would not be the only one using it, I bet the script could be 
upstream'ed to git.

Cheers,
  Jędrek


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

On 23.1.2019 17.51, Jedrzej Nowacki wrote:
>Can we use annotate instead of cherry-pick -x?
>--
> 
>No, but we should use it in addition. Annotations are mutable, therefore 
> are
> not 100% trust worthy. If we have both, we could validate annotations against
> commit message, sadly it would not protect against annotation removal.

What are these annotations? I tried to google them but only found documentation
for git-annotate, which is just git-blame with a different output format.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Vitaly Fanaskov]

>Why not X instead?
>--
>
>- GitFlow, GitHub <= both are based on feature branches, that doesn't work
> well with gerrit.
So, the only problem here is gerrit (aside from personal preferences and 
habits of course). The question is shouldn't we abandon gerrit as this 
tool doesn't feet with the needs well? Inventing new approaches is of 
course super cool... But not always necessary.

What's wrong with using, say, gitflow + gitlab + upsource? Upsource is 
optional, but it's the way better for code review than gerrit.

On 1/23/19 4:51 PM, Jedrzej Nowacki wrote:
> Hi,
>
>It is time to rethink our branch model. We are approaching Qt6 development
> and I'm worried that what we have now, will simply not scale. As you know, our
> branch model is mainly(*) based on merging from stable up to development
> branches. In general, it is a very good model, which make sure that release
> branches are not getting obsolete too quickly, that most of the fixes are in
> the right places, that every commit is only once in the git history. It is a
> very clean model. It is also a very slow model, with a single point of
> failure.
>
>It is hard to maintain:
>My impression is that the current model works great for a single release
> branch, but we have: 5.6 5.9 5.12 and soon we will have 5.13, that is without
> counting temporary patch level branches. Merging through them is hard, we
> already had to use "cherry-pick mode" in some places. When we add to the
> picture dev and qt6 branches, merging will be very, very hard. It is
> practically a full time job to update qt5 repository and coordinate all the
> merges now (thank you Liang!), shortly after qt6 branch opening amount of work
> will be much bigger.
>It is slow:
>The merges take time. We produce a lot of code, we have a lot of tests that
> needs to pass. Even single failure delays merge propagation by at least one
> day. If by bad luck, the merge contains some API incompatible changes an
> intermediate jump through Qt5 integration is required, that adds at least 3
> days of delay.
>
>--
>
>Proposal in short: let's use cherry-pick mode everywhere.
>
>All(**) changes would go to dev. From which they would be automatically
> cherry-picked by a bot to other branches. The decision to which branch cherry-
> pick, would be taken based on a tag in the commit message. We could add a
> footer that marks the change risk level as in quip-5 
> (http://quips-qt-io.herokuapp.com/quip-0005.html), so for example "dev", 
> "stable", "LTS". By
> default everything would be cherry-picked to qt6 branch unless "no-future" tag
> would be given. Of course we can bike-shed about the tag names.
>
>Advantages:
>- no waiting for merges, a fix can be used right away after integration
>- faster propagation of fixes targeting all branches, as there are no 
> merges
> of merges
>- simpler for new contributors, always push to dev
>- in most cases a reviewer does no need to know what the current version
> number is
>- conflict resolution is distributed and affects mostly the author of the
> change
>- documents a change intent, which may be useful for people keeping own
> forks
>- over time with increased amount of conflicts old branches, in natural 
> way,
> stay untouched
>
>Disadvantages:
>- git history would be a bit wilder, "git branch --contains" would not work
>- commit messages in some branches would have kind of ugly footer as an
> effect of "cherry-pick -x"
>- there is a chance, that some cherry-picked commits may be left forgotten
> in gerrit after a failed integration
>
>Bot details:
>
>The bot would listen only for changes in dev, in some unusual cases one
> could target an other branch directly, but bot would not trigger automatic
> cherry-pick(***). The bot would wait for a successful dev integration before
> creating cherry-picked changes. The bot would use cherry-pick -x to annotate
> the origin patch. After the cherry-pick creation, it would push it to gerrit,
> +2 and stage once. It would be up to the author to re-stage in case of
> flakiness. In case of a cherry-pick conflict it should push unresolved 
> conflict
> to gerrit and add all reviewers and author to handle the issue.
>
> The list below shows branch targets for automatic cherry-pick based on given
> tag.
>
> dev (qt6)
> stable (qt6, 5.13)
> stable, no-future (5.13)
> LTS (qt6, 5.13, 5.12)
> LTS-strict (qt6, 5.13, 5.12, 5.9)
> LTS, no-future (5.13, 5.12)
>
> That is assuming that we have branches: qt6  dev  5.13  5.13.q  5.12  5.12.w
> 5.9  5.9.e  5.6  5.6.r
> I think we should assume that patch level branches, as well LTS in very strict
> state, are handled manually.
>
>
>Creation of new branches:
> We would branch more or less as usual. The only difference from the current
> system is that we would not need the back merge / soft branching 

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

On 24.1.2019 11.49, Edward Welbourne wrote:
> Olivier Goffart (24 January 2019 08:03)
>> Let's start by looking at the "problem"
> 
> Always a good place to start.
> 
> On 23.01.19 16:51, Jedrzej Nowacki wrote:
>>> My impression is that the current model works great for a single
>>> release branch, but we have: 5.6 5.9 5.12 and soon we will have 5.13,
>>> that is without counting temporary patch level branches.
> 
>> But the LTS and patch level branches are already in cherry-pick mode!
> 
> Indeed: Jedrzej does here over-state the problem.
> 
>> So we have only ever have one release branch. Therefore the current
>> model works great (your own words).
> 
> We routinely have two branches other than dev that are merged up to dev,
> one via the other.  Thus, until 5.11 closed, we were merging 5.11 up
> through 5.12 to dev; once 5.13 branches, we'll be merging 5.12 through
> 5.13 up to dev.  Once 5.13 closes, we'll put 5.12 in cherry-pick mode
> and be back to just one (as we are right now, temporarily); but wne 5.15
> branches we'll be back to 5.14 -> 5.15 -> dev again.  Then, of course,
> we also have the 5.x.y branches transiently, which does complicate life,
> but I'm going to leave it out of my analysis.
> 
> So some of the time we have three branches, some of the time two,
> between which we merge; plus we have an LTS or two to which we
> cherry-pick.  (Which means we mix models.)
> 
> However, merge-mode always implies more delay for a change's propagation
> compared to the cherry-pick model, at least when the developer whose
> change is considered is eager to get it propagated.

In general it leads to a longer delay until the change is in all relevant
branches. It does however lead to a change getting into the branch closest to
release faster, because it doesn't need to get into dev first. Branches close to
release are an important case.

Yes, you can deviate from the process in urgent cases. But even if the release
is not right at the door to justify the deviation, the change landing sooner
gives more time to find any possible issues in it.

> 
>>> Merging through them is hard, we already had to use "cherry-pick
>>> mode" in some places. When we add to the picture dev and qt6
>>> branches, merging will be very, very hard. It is practically a full
>>> time job to update qt5 repository and coordinate all the merges now
>>> (thank you Liang!),
> 
>> But as other have already said, the total amount of work would still be the
>> same. Actually worse since one would have to manually stage the patch and 
>> fail
>> the tests and resolve the conflicts that happen between them as they may 
>> occurs
>> in different order.  Overall, i'd say this is much more burden for branches
>> which still are supposed to get lots of patches.
> 
> There would, indeed, be extra staging with the proposed model; and
> patches may land in a different order.  The latter bothers me more.

Add to that the fact that a long-lived branch that is cherry-picked to may lead
to having to resolve the same conflict multiple times. (As discussed elsewhere
in the thread.)

Especially so for qt6 branch, which would be getting almost every change made in
dev + API breaking changes preparing for Qt 6. How many changes will actually
have the no-future tag?

>>> shortly after qt6 branch opening amount of work will be much bigger.
> 
>> But I fail to see how the proposed model helps with that in any way.
> 
> ... and we'll eventually have to merge the qt6 branch with dev, which is
> going to be "fun" if they've had cherry-picks between them that have had
> conflicts (as we can expect) that have been resolved.  Whoever does that
> merge is going to wish we'd been using merges from dev to qt6 earlier.

If I understood the proposal right, there wouldn't be a merge from dev into the
qt6 branch. Rather the dev branch would be deleted and the qt6 branch renamed to
dev. It already has all the changes, except those with the tag no-future

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Edward Welbourne]

On 24.1.2019 11.13, Edward Welbourne wrote:
>> A cherry-pick takes the diff involved in one commit and patches
>> another check-out with it.  A merge uses the digraph of commits in
>> sophisticated ways; a cherry-pick does not.

Kari Oikarinen (24 January 2019 10:33)
> Quoting man page for git-cherry-pick: https://git-scm.com/docs/git-cherry-pick
>
> "For conflicting paths, the index file records up to three versions,
> as described in the "TRUE MERGE" section of git-merge[1]. The working
> tree files will include a description of the conflict bracketed by the
> usual conflict markers <<< and >>>."
>
> It is similar enough that it actually refers to the same section of
> documentation!

I stand corrected.
Time to re-read the cherry-pick docs.
My apologies to Allan for my misunderstanding.

> But it doesn't actually create a new common ancestor for the
> commits. So every further cherry-pick can still hit the same
> conflict. Instead of being resolved by the merge, there's an unbounded
> amount of time that different people will hit it and need to resolve
> it.

That's a good point.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

On 24.1.2019 11.11, Volker Hilsheimer wrote:
> 
> 
>> On 23 Jan 2019, at 22:09, Allan Sandfeld Jensen > > wrote:
>>
>> On Mittwoch, 23. Januar 2019 21:42:35 CET Edward Welbourne wrote:
>>> Jedrzej Nowacki wrote:
> Advantages:
> - no waiting for merges, a fix can be used right away after
>
>   integration
>
> - faster propagation of fixes targeting all branches, as there are
>
>   no merges of merges
>>>
>>> Alex Blasche (23 January 2019 18:09)
>>>
 This is pure speculation because you potentially triple (or worse) the
 amount of individual patches requiring a merge in gerrit when you
 consider that you want to at least merge to 5.9, 512, dev and qt6. I
 don't see this prediction come true.
>>>
>>> Well, as soon as it hits dev, the patch is cherry-picked to every branch
>>> that its footer says it belongs in.  Those branches where all goes well
>>> see it one integration later.  Each branch that has a conflict needs
>>> that resolved before we get to that second integrtion.  Contrast this
>>> with a 5.12 -> 5.13 -> dev chain of merges, where dev doesn't get the
>>> change that landed in 5.12 (even if that change could land in dev
>>> without conflict) until
>>> * there's been some delay between their change being accepted in 5.12
>>>   and the next merge-bot run
>>> * everyone who made change to 5.12 that conflicted on merging to 5.13
>>>   has advised Liang on how to resolve their conflicts
>>> * we've got the result through integration into 5.13
>>> * everyone who's made changes to 5.13 or (as possibly just amended in
>>>   merging) 5.12 that conflicts with anything in dev has again advised
>>>   how to resolve their conflicts
>>> * and we've got the result through a second integration, into dev.
>>>
>>> When nothing but the change being considered has a conflict along
>>> the way, that's twice as long; and any change to an upstream branch,
>>> that does have a conflict, introduces delay for all the other changes
>>> that landed in that branch, even if they don't have conflicts.  In the
>>> middle of summer, when lots of folk are away on holiday, getting help
>>> with resolving conflicts isn't easy - the folk who know those commits
>>> won't be back for a month - and all changes, no matter how urgent, get
>>> stuck behind any conflict we can't work out how to resolve.
>>>
>>> So no, Jedrzej's claim is not *pure* speculation; it's at least quite a
>>> lot adulterated with reasons to believe that many changes would, under
>>> his scheme, propagate to all branches they're destined for sooner than
>>> happens with our present scheme.
>>>
>> No, it is speculation, and it optimizing the least important case: bug-fixes
>> in dev. Dev is the branch that can wait the longest to get a bug-fix, the
>> stable branch is the branch that need it the most urgent. And fixing a bug in
>> 5.12 now means you first fix it where you need it (5.12), then rewrite it for
>> dev, then resolve the inevitable conflict back so it can be merged, all
>> waiting for bots and release teams to stumple into the issues and delaying 
>> the
>> next 5.12.x release.
>>
>> ‘Allan
> 
> 
> More people working and building against dev helps keep dev more stable (by 
> virtue of discovering breakage sooner), and the proposal encourages more 
> people 
> to work on dev. That can be a good thing.

Our users use our releases. Our development process should aim at producing good
releases (at scheduled times). This proposal is putting more focus on dev, but
will it lead to better quality releases? Users won't care about a dev branch
that gets fixes sooner, if they have to wait for those important fixes longer
than in the current situation.

> 
> Urgency to get fixes into a stable branch is an argument that has come up a 
> few 
> times. The current 5.12.1 release seems to be delayed because some changes 
> made 
> it into 5.12 that shouldn’t have been there in the first place (given the 
> definition of “stable”). It would be interesting to see some data about how 
> many 
> point releases we had to delay because “highly desirable fix for old bug was 
> stuck in the process” vs “regression was introduced in a stable branch and 
> only 
> discovered during release testing”.

The absolute path changes got into 5.12.1 due to an explicit wish to have them
in a fresh LTS branch early. Reviewers accepted that and could have done so
under both models as easily.

The argument that these changes help by reducing changes in stable branches is
that currently people are putting in changes that don't belong there. Making
getting changes into stable branches more painful with the new model will lead
to less changes getting in. This will happen due to people avoiding work they
can avoid.

Importantly this is not the same thing as more careful consideration about
whether a change *should* go to the stable branch. The changes will be selected
based on how persistent people are, not on how 

Re: [Development] Proposal: New branch model

[Edward Welbourne]

Olivier Goffart (24 January 2019 08:03)
> Let's start by looking at the "problem"

Always a good place to start.

On 23.01.19 16:51, Jedrzej Nowacki wrote:
>>My impression is that the current model works great for a single
>> release branch, but we have: 5.6 5.9 5.12 and soon we will have 5.13,
>> that is without counting temporary patch level branches.

> But the LTS and patch level branches are already in cherry-pick mode!

Indeed: Jedrzej does here over-state the problem.

> So we have only ever have one release branch. Therefore the current
> model works great (your own words).

We routinely have two branches other than dev that are merged up to dev,
one via the other.  Thus, until 5.11 closed, we were merging 5.11 up
through 5.12 to dev; once 5.13 branches, we'll be merging 5.12 through
5.13 up to dev.  Once 5.13 closes, we'll put 5.12 in cherry-pick mode
and be back to just one (as we are right now, temporarily); but wne 5.15
branches we'll be back to 5.14 -> 5.15 -> dev again.  Then, of course,
we also have the 5.x.y branches transiently, which does complicate life,
but I'm going to leave it out of my analysis.

So some of the time we have three branches, some of the time two,
between which we merge; plus we have an LTS or two to which we
cherry-pick.  (Which means we mix models.)

However, merge-mode always implies more delay for a change's propagation
compared to the cherry-pick model, at least when the developer whose
change is considered is eager to get it propagated.

>> Merging through them is hard, we already had to use "cherry-pick
>> mode" in some places. When we add to the picture dev and qt6
>> branches, merging will be very, very hard. It is practically a full
>> time job to update qt5 repository and coordinate all the merges now
>> (thank you Liang!),

> But as other have already said, the total amount of work would still be the
> same. Actually worse since one would have to manually stage the patch and fail
> the tests and resolve the conflicts that happen between them as they may 
> occurs
> in different order.  Overall, i'd say this is much more burden for branches
> which still are supposed to get lots of patches.

There would, indeed, be extra staging with the proposed model; and
patches may land in a different order.  The latter bothers me more.

>> shortly after qt6 branch opening amount of work will be much bigger.

> But I fail to see how the proposed model helps with that in any way.

... and we'll eventually have to merge the qt6 branch with dev, which is
going to be "fun" if they've had cherry-picks between them that have had
conflicts (as we can expect) that have been resolved.  Whoever does that
merge is going to wish we'd been using merges from dev to qt6 earlier.

>>It is slow:
>>The merges take time. We produce a lot of code, we have a lot of tests 
>> that
>> needs to pass. Even single failure delays merge propagation by at least one
>> day. If by bad luck, the merge contains some API incompatible changes an
>> intermediate jump through Qt5 integration is required, that adds at least 3
>> days of delay.

> Incompatile changes should not happen in a release branch normally. (Or very
> seldomly, as fixes on new API)

No, but they do happen in dev, which complicates merging things up to
dev - which, I suppose, was Jedrzej's point.

> And as it has been said already, there is no priority to get changes quick in
> the dev branch. On the other hand, haing the change faster in the stable 
> branch
> are more important, for it is going to be released first. So your model would
> delay the change in the branch where it matters more.

The delay would only happen to things that got conflicts or on which CI
failed; and, as long as someone's eager to get the change into the
target branch, it's likely to be delayed by at most about a day.  In
contrast, when we do have three branches, the fix in a release branch
takes several days to reach the stable branch and about a week to reach
dev.

When the fix is for breakage that's causing Coin failures, that's
holding up everyone for a week.  We get this not so infrequently.  With
the cherry-pick model, the fix would be done first in dev and would
reach all other affected branches probably within a day.

>[...]
>>- Stay with the current solution <= the merge effort is too big and qt6 is
>> expected to cause conflicts that really should not be solved by one person

> Again, I don't see how the proposed model reduce the amount of
> conflicts.

It doesn't.  It does, however, ensure that conflicts are dealt with by
the people who made the change on one side of the conflict, while the
change is still fresh in their minds.  That is probably better than
having the conflict resolved by someone who knows neither half of the
change.  OTOH, it runs the risk that the other side of the conflict
won't be properly understood by those resolving it, creating an
asymmetry that's absent when the resolver is equally ignorant of both
sides.

> 

Re: [Development] Proposal: New branch model

[Volker Hilsheimer]

> On 24 Jan 2019, at 09:22, Jaroslaw Kobus  wrote:
>>> "All(**) changes would go to dev. From which they would be automatically
>>> cherry-picked by a bot to other branches. The decision to which branch 
>>> cherry-
>>> pick, would be taken based on a tag in the commit message. We could add a
>>> footer that marks the change risk level as in quip-5"
>>> 
>>> No sure I understand the above correctly. Let's say in dev branch some 
>>> source file got refactored completely, so that no single line match the old 
>>> version anymore, e.g. Qt 5.9. Now you need to fix the old code, which is in 
>>> 5.9 branch - how in this case you may try to push your fix to dev?
>>> 
>>> Jarek
>>> 
>> That’s where the “with exception of branch specific changes” clause (which 
>> the ** points at) kicks in.
>> 
>> Is the fix needed in dev (or is the bug fixed by the refactoring)?
>> 
>> If yes, then fix it in dev, and then make a separate fix in the relevant LTS 
>> branches (perhaps starting with the cherry-pick’ed change). Or just accept 
>> that this bug won’t/can’t be fixed in the pre-refactoring codebase.
>> 
>> If no, then push the fix for the newest branch where it’s needed, from where 
>> it can be cherry picked further; don’t do anything in dev (including “don’t 
>> expect someone that knows nothing about your change to deal with the merge 
>> conflict”).
>> 
> In this case there is additional step then. You would be forced now to check 
> first both 5.9 and dev branches and detect if a fix would be "applyable" to 
> the dev or not.


Testing whether the bug that I’m fixing exists in dev or not is part of the 
drill of fixing bug, isn’t it? Why would you spend time on fixing something in 
5.12 without checking whether the issue is still present in the latest 
codebase? Perhaps the issue has been fixed already, just without the author 
considering it relevant for 5.12 (perhaps for good reasons).


> Besides, if you decide that your fix goes only to the 5.9 branch - in this 
> case you follow the current model anyway, right? So, having two models isn't 
> better than having just one I think.


With the proposed model there are no more automatic merges from more stable to 
less stable, so once my change made it into 5.9, that is it.


Volker


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Oswald Buddenhagen]

On Thu, Jan 24, 2019 at 09:13:32AM +, Edward Welbourne wrote:
> A cherry-pick takes the diff involved in one commit and patches another
> check-out with it.  A merge uses the digraph of commits in sophisticated
> ways; a cherry-pick does not.
> 
uhhh, actually, it does. cherry-pick even has the --strategy option from
merge.
compare also git am -3.

it seems plausible that a longer series of cherry-picks to the same area
would increasingly defeat the merge logic.

while at it, i'll also note that last time i checked git was somewhat
weak for a cherry-picking workflow compared to subversion and a bunch of
other VCSs aimed at exclusively linear histories, because it doesn't
record where commits were picked _to_ (though that would be actually
implementable on top of notes).
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Allan Sandfeld Jensen]

On Donnerstag, 24. Januar 2019 10:13:32 CET Edward Welbourne wrote:
> OK, now you're just engaging in ill-informed FUD.
> Cherry-picks do not involve any three-way anything.
> You clearly do not understand the difference between merging and
> cherry-picking.
> 
> A cherry-pick takes the diff involved in one commit and patches another
> check-out with it.  A merge uses the digraph of commits in sophisticated
> ways; a cherry-pick does not.
> 
They do on my machine when I do git git cherry-picks. I do that about a 
hundred times every month when maintaining qtwebengine, and I use the three 
way diff to resolve conflicts. They way I avoid the three way diff getting 
useless is by resetting the chromium fork regularly, so there is always a 
nearest common ancestor at the last fork point.

Git performs merges and cherry-picks the same way, the main difference is how 
they are recorded in the history, where merges provide a better history to do 
future merges and cherry-picks on.

'Allan





___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Kari Oikarinen]

On 24.1.2019 11.13, Edward Welbourne wrote:
> 23.01.2019, 21:38, "Alex Blasche" :
 At the end of the day each cherry-pick is a merge too
> 
> Merges and cherry-picks have a certain amount in common, but they are
> not the same thing at all.
> 
 and they can conflict too. The conflict resolution process is still
 the same. if everything is conflict free then a git merge would be
 no more difficult than a cherry-pick.
> 
> This is true.
> 
> On Mittwoch, 23. Januar 2019 19:43:06 CET Konstantin Tokarev wrote:
>>> And when conflicts are present, cherry-picking N patches may result in N
>>> times more work than merge in worst case (and same amount of work in the
>>> best case)
> 
> Allan Sandfeld Jensen (23 January 2019 23:05)
>> More than that. Once you have had cherry-pick only for a while git will be
>> unable to find useful common ancestors for the changes, and will be unable to
>> do smart three-way merging of cherry-picks,
> 
> OK, now you're just engaging in ill-informed FUD.
> Cherry-picks do not involve any three-way anything.
> You clearly do not understand the difference between merging and
> cherry-picking.
> 
> A cherry-pick takes the diff involved in one commit and patches another
> check-out with it.  A merge uses the digraph of commits in sophisticated
> ways; a cherry-pick does not.
> 

Quoting man page for git-cherry-pick: https://git-scm.com/docs/git-cherry-pick

"For conflicting paths, the index file records up to three versions, as 
described in the "TRUE MERGE" section of git-merge[1]. The working tree files 
will include a description of the conflict bracketed by the usual conflict 
markers <<< and >>>."

It is similar enough that it actually refers to the same section of
documentation!

But it doesn't actually create a new common ancestor for the commits. So every
further cherry-pick can still hit the same conflict. Instead of being resolved
by the merge, there's an unbounded amount of time that different people will hit
it and need to resolve it.

-- 
Kari
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Allan Sandfeld Jensen]

On Donnerstag, 24. Januar 2019 10:11:35 CET Volker Hilsheimer wrote:
> More people working and building against dev helps keep dev more stable (by
> virtue of discovering breakage sooner), and the proposal encourages more
> people to work on dev. That can be a good thing.
 
No,  it will overload the CI by having all integrations happen on the same 
branch, instead being able to integrate multiple branches at once.

> Urgency to get fixes into a stable branch is an argument that has come up a
> few times. The current 5.12.1 release seems to be delayed because some
> changes made it into 5.12 that shouldn’t have been there in the first place
> (given the definition of “stable”). It would be interesting to see some
> data about how many point releases we had to delay because “highly
> desirable fix for old bug was stuck in the process” vs “regression was
> introduced in a stable branch and only discovered during release testing”.
> 
I dont see that. 5.12.1 branched a long time ago and very early, patches in 
5.12 shouldnt affect it. It is stalled because certain things needs to be 
fixed that arent fixed.

> Without data, I would speculate that perhaps a model that leads to fewer
> changes made to stable branches because it requires an explicit decision
> (and perhaps extra work) to get changes there is not such a terrible idea.
> And making the work to make changes to a stable branch, ie the cost of
> maintenance, very visible is also a good thing.
 
> Either way, nothing in the proposal prevents us from developing and push a
> fix for 5.12, and then develop a different fix for dev that we don’t cherry
> pick into 5.12 or other stable branches. This should be an exception, used
> in urgent situations where indeed we can’t wait. For those cases, there’s
> no merge conflict in the first place in the new model (because there’s no
> merge).
 
It is still doing merging the wrong way for no good reason. Even if cherry-
picking itself wasnt a bad idea. You could just as well commit to the stable 
branch first and then cherry-pick it to the other branches. That way there 
would be no need for cryptic annotations, the branches to pick to would be 
implicit from where the patch first landed. Or even better, you could perform 
a merge to dev on every single commit to the stable branch, or even better, 
only create a merge if there are conflicts, so we don't overload the CI on 
dev.

'Allan



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Volker Hilsheimer]

> On 24 Jan 2019, at 08:03, Olivier Goffart  wrote:
> [...]>- Stay with the current solution <= the merge effort is too big and 
> qt6 is
>> expected to cause conflicts that really should not be solved by one person
> 
> Again, I don't see how the proposed model reduce the amount of conflicts.
> If the "one person" is the problem, then nothing prevents you to assign more 
> people to the job. One easy way is already to share the different modules 
> (repositories). But with some cooperation it is also possible to share the 
> work accross directories, or by number of commits. One can also be pragmatic 
> and revert most problematic commit (that fails tests) in dev or stable, then 
> let the author work at it again.

Having to wait for someone else to trigger the merge and resolve the various 
conflicts before I can continue to base my work on dev on a fix that I already 
made in 5.12 breaks flow. Distributing this work to more people doesn’t solve 
the problem.

The whole notion that my change has to become someone else’s problem by design 
of the merge process is more than just a little crazy to me. I want to own my 
change, have control over which branches it hits, and be responsible for 
cleaning up the mess my change might have caused. The current model doesn’t 
give me any of that beyond the initial merge.

Volker

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Edward Welbourne]

23.01.2019, 21:38, "Alex Blasche" :
>>> At the end of the day each cherry-pick is a merge too

Merges and cherry-picks have a certain amount in common, but they are
not the same thing at all.

>>> and they can conflict too. The conflict resolution process is still
>>> the same. if everything is conflict free then a git merge would be
>>> no more difficult than a cherry-pick.

This is true.

On Mittwoch, 23. Januar 2019 19:43:06 CET Konstantin Tokarev wrote:
>> And when conflicts are present, cherry-picking N patches may result in N
>> times more work than merge in worst case (and same amount of work in the
>> best case)

Allan Sandfeld Jensen (23 January 2019 23:05)
> More than that. Once you have had cherry-pick only for a while git will be
> unable to find useful common ancestors for the changes, and will be unable to
> do smart three-way merging of cherry-picks,

OK, now you're just engaging in ill-informed FUD.
Cherry-picks do not involve any three-way anything.
You clearly do not understand the difference between merging and
cherry-picking.

A cherry-pick takes the diff involved in one commit and patches another
check-out with it.  A merge uses the digraph of commits in sophisticated
ways; a cherry-pick does not.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Volker Hilsheimer]

On 23 Jan 2019, at 22:09, Allan Sandfeld Jensen 
mailto:k...@carewolf.com>> wrote:

On Mittwoch, 23. Januar 2019 21:42:35 CET Edward Welbourne wrote:
Jedrzej Nowacki wrote:
Advantages:
- no waiting for merges, a fix can be used right away after

  integration

- faster propagation of fixes targeting all branches, as there are

  no merges of merges

Alex Blasche (23 January 2019 18:09)

This is pure speculation because you potentially triple (or worse) the
amount of individual patches requiring a merge in gerrit when you
consider that you want to at least merge to 5.9, 512, dev and qt6. I
don't see this prediction come true.

Well, as soon as it hits dev, the patch is cherry-picked to every branch
that its footer says it belongs in.  Those branches where all goes well
see it one integration later.  Each branch that has a conflict needs
that resolved before we get to that second integrtion.  Contrast this
with a 5.12 -> 5.13 -> dev chain of merges, where dev doesn't get the
change that landed in 5.12 (even if that change could land in dev
without conflict) until
* there's been some delay between their change being accepted in 5.12
  and the next merge-bot run
* everyone who made change to 5.12 that conflicted on merging to 5.13
  has advised Liang on how to resolve their conflicts
* we've got the result through integration into 5.13
* everyone who's made changes to 5.13 or (as possibly just amended in
  merging) 5.12 that conflicts with anything in dev has again advised
  how to resolve their conflicts
* and we've got the result through a second integration, into dev.

When nothing but the change being considered has a conflict along
the way, that's twice as long; and any change to an upstream branch,
that does have a conflict, introduces delay for all the other changes
that landed in that branch, even if they don't have conflicts.  In the
middle of summer, when lots of folk are away on holiday, getting help
with resolving conflicts isn't easy - the folk who know those commits
won't be back for a month - and all changes, no matter how urgent, get
stuck behind any conflict we can't work out how to resolve.

So no, Jedrzej's claim is not *pure* speculation; it's at least quite a
lot adulterated with reasons to believe that many changes would, under
his scheme, propagate to all branches they're destined for sooner than
happens with our present scheme.

No, it is speculation, and it optimizing the least important case: bug-fixes
in dev. Dev is the branch that can wait the longest to get a bug-fix, the
stable branch is the branch that need it the most urgent. And fixing a bug in
5.12 now means you first fix it where you need it (5.12), then rewrite it for
dev, then resolve the inevitable conflict back so it can be merged, all
waiting for bots and release teams to stumple into the issues and delaying the
next 5.12.x release.

‘Allan


More people working and building against dev helps keep dev more stable (by 
virtue of discovering breakage sooner), and the proposal encourages more people 
to work on dev. That can be a good thing.

Urgency to get fixes into a stable branch is an argument that has come up a few 
times. The current 5.12.1 release seems to be delayed because some changes made 
it into 5.12 that shouldn’t have been there in the first place (given the 
definition of “stable”). It would be interesting to see some data about how 
many point releases we had to delay because “highly desirable fix for old bug 
was stuck in the process” vs “regression was introduced in a stable branch and 
only discovered during release testing”.

Without data, I would speculate that perhaps a model that leads to fewer 
changes made to stable branches because it requires an explicit decision (and 
perhaps extra work) to get changes there is not such a terrible idea. And 
making the work to make changes to a stable branch, ie the cost of maintenance, 
very visible is also a good thing.

Either way, nothing in the proposal prevents us from developing and push a fix 
for 5.12, and then develop a different fix for dev that we don’t cherry pick 
into 5.12 or other stable branches. This should be an exception, used in urgent 
situations where indeed we can’t wait. For those cases, there’s no merge 
conflict in the first place in the new model (because there’s no merge).


Volker



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Jaroslaw Kobus]

From: Volker Hilsheimer
Sent: Wednesday, January 23, 2019 5:25 PM
To: Jaroslaw Kobus
Cc: Jedrzej Nowacki; development@qt-project.org
Subject: Re: [Development] Proposal: New branch model

On 23 Jan 2019, at 17:08, Jaroslaw Kobus 
mailto:jaroslaw.ko...@qt.io>> wrote:

"All(**) changes would go to dev. From which they would be automatically
cherry-picked by a bot to other branches. The decision to which branch cherry-
pick, would be taken based on a tag in the commit message. We could add a
footer that marks the change risk level as in quip-5"

No sure I understand the above correctly. Let's say in dev branch some source 
file got refactored completely, so that no single line match the old version 
anymore, e.g. Qt 5.9. Now you need to fix the old code, which is in 5.9 branch 
- how in this case you may try to push your fix to dev?

Jarek


That’s where the “with exception of branch specific changes” clause (which the 
** points at) kicks in.

Is the fix needed in dev (or is the bug fixed by the refactoring)?

If yes, then fix it in dev, and then make a separate fix in the relevant LTS 
branches (perhaps starting with the cherry-pick’ed change). Or just accept that 
this bug won’t/can’t be fixed in the pre-refactoring codebase.

If no, then push the fix for the newest branch where it’s needed, from where it 
can be cherry picked further; don’t do anything in dev (including “don’t expect 
someone that knows nothing about your change to deal with the merge conflict”).


Volker


In this case there is additional step then. You would be forced now to check 
first both 5.9 and dev branches and detect if a fix would be "applyable" to the 
dev or not.

Besides, if you decide that your fix goes only to the 5.9 branch - in this case 
you follow the current model anyway, right? So, having two models isn't better 
than having just one I think.

Jarek
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: New branch model

[Liang Qi]

Lots of talks happened already on this thread.

I would like to think old model as "merge" model VS new model as
"cherry-pick" model.

In the old "merge" model, normally we will drop a branch out to
cherry-pick mode after having more than 3 branches and try to have 2
branches(change LTS branch to cherry-pick mode after a while). The
worst case is when we have 5.12/5.13/dev branches with regular
5.12->5.13->dev merges, and also 5.12.x and 5.13.y release branches,
more merges involved. You can imagine the "chaos" when a critical fix
is needed for multiple branches, especially the delay for development
in dev branch.

In this scenario, I will trigger a qt5 integration(with latest sha1
from all submodules) in 5.12, it will take about 1 day(at least 8
hours, a work day) to see whether it is broken or not. After fix
everything in 5.12, I will try 5.13, same process, and dev. The whole
round is quite painful, especially around feature frozen period, if
some API changes happened, more ping-pong rounds are involved, more
details see 
https://lists.qt-project.org/pipermail/development/2016-October/055084.html
(old url was invalid any more, after the mailing list scripts
regenerated the web pages.)

From last year(2018), I had a merge script/bot
(https://codereview.qt-project.org/#/q/owner:%22Qt+Forward+Merge+Bot%22,n,z)
to do the merge work, it checks qtbase and qtdeclarative daily, and do
merge if more than 5 new changes happened. And check other modules
twice a week, and do merge if there is new change old than 1 week.
BTW, qtwebengine is a bit special, and some module maintainers(like
J-P for qtquickcontrols2) triggered the merge regularly by themselves.

With merge model, and the bot, this situation also happened regularly.
Like my current attempt to have a qt5 5.12->dev merge plus a qt5 dev
submodule update,

* https://codereview.qt-project.org/#/c/249863/
* https://codereview.qt-project.org/#/c/250191/

* https://bugreports.qt.io/browse/QTBUG-72953
* https://bugreports.qt.io/browse/QTBUG-73224

Both related with changes in qtdeclarative 5.12(one is a fix for
QTBUG-72953, another is the source of QTBUG-73224), but a 5.12->dev
merge will bring them together to dev, I need to wait for a totally
fixed 5.12 for current qt5 dev integration, including fix in
qtwebengine and other modules. The current estimated time is 3 days or
a week.

In the "cherry-pick" model, we can think every other branches than dev
are in locked mode, controlled by release team or module maintainers.
The developers of patches will not be involved if "cherry-pick" bot
doesn't find conflicts and CI/COIN approved it.

The amount of total conflicts will be same in both models. The
difference is who is reponsible to fix it. I am the center point to
fix them currently, but it's very difficult to know the situation in
different branches in the whole qt5 umbrella. With new cherry-pick
mode, the owner of the change will be notified if conflicts happened.
I suggest it should also notify the module maintainer and release
team. Those people are more responsible than anyone else to have the
change happened in the target branches. And it will not block the
development in dev.

In new model, perhaps a merge monkey is not needed any more, but a
cherry-pick monkey will happen. And with the direct help from the
owner of the change, and not blocking dev branch, I consider it as
less pressure personally.

My concern is about "cherry-pick" a series of changes for a big
feature, especially during the period to have "dev" branches for both
5 and 6. I don't have solution for this issue yet.

Best regards,
Liang
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development