[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