Am 25.01.2019 um 11:08 schrieb Lars Knoll: > > > On 25 Jan 2019, at 10:10, Simon Hausmann > <[email protected]<mailto:[email protected]>> 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. > > The risk with this is that we might end up having fixes in a stable branch > that don’t make it do dev for various reasons, so it’ll regress in the next > minor release. > > > (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. > > The CI problem comes from the fact that if we have a high rate of stages to > qtbase/dev, we at some point get into a deadlock situation, even if we > disregard any flakiness in the system. That’s because higher rates imply that > more changes are tested together. This in turn increasing the risk of > rejection of all changes because of one bad change in the set. So the current > system doesn’t scale and basically rate limits the amount of changes going > into a branch (or worse, we end up getting traffic jams where the actual rate > actually goes down to zero). > > To me this means we need to seriously rethink that part of our CI system, and > ideally test changes (or patch series) individually and in parallel. So maybe > we should adjust our CI system that way: > > * test changes (or patch series) individually > * If they pass CI merge or cherry-pick them into the branch > * reject only if the merge/cherry-pick gives conflicts > > This adds a very small risk that two parallel changes don’t conflict during > the merge/cherry-pick process, but cause a test regression together. To help > with that, we can simply run a regular status check on the repo. If this > happens the repo will be blocked for further testing until someone submits a > fix or reverts an offending change, which is acceptable.
Could that be solved by testing the combinations of changes again? * test changes (or patch series) individually * If they pass CI merge or cherry-pick them into some local branch * reject if the merge/cherry-pick gives conflicts * when time period x has passed or the local branch contains y changes, test the local branch good: push the local branch to the public one bad: repeat step four with a subset of the changes it had before Assuming that y is significantly greater than 1, the added overhead for one more test run seems relatively small to me. Cheers, Robert > > Another advantage is that this would pave the road towards a system where CI > testing happens before human review, so we can in the longer term avoid > duplicated review/approval work. > > Cheers, > Lars > > > > > 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 >> <[email protected]<mailto:[email protected]>> wrote: >> >> On Thu, 24 Jan 2019 at 20:26, Simon Hausmann >> <[email protected]<mailto:[email protected]>> 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 [email protected] https://lists.qt-project.org/listinfo/development
