[Development] Proposal: New branch model
Jedrzej.Nowacki at qt.io
Thu Jan 24 16:21:27 CET 2019
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
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.
More information about the Development