[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