[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 <development-bounces at qt-project.org> on behalf of Allan Sandfeld Jensen <kde at carewolf.com>
Sent: Thursday, January 24, 2019 1:33:28 PM
To: Jedrzej Nowacki
Cc: development at 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)
- 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 at qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190125/fc236fdf/attachment.html>