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 <ville.voutilai...@gmail.com> >> wrote: >> >> On Thu, 24 Jan 2019 at 20:26, Simon Hausmann <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 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 > -- --- Kari Oikarinen Senior Software Engineer The Qt Company Elektroniikkatie 13 90590, Oulu, Finland kari.oikari...@qt.io +358 50 5281010 http://qt.io ---
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development