> On 25. Jan 2019, at 11:08, Lars Knoll <lars.kn...@qt.io> wrote: > > > >> On 25 Jan 2019, at 10:10, Simon Hausmann <simon.hausm...@qt.io> 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.
Note that this risk exists partially even if fixes are first pushed into dev and then from dev directly to multiple “stable” branches. Fix goes into dev. Fix is cherry-picked into 5.9 without issues. Fix is cherry-picked into 5.12 and for whatever reason there are issues with that. There is a risk that the bug will not be fixed in the next (or any) 5.12 release even though it already is fixed in 5.9. Granted, it will be fixed in 5.13 again. This is also not ideal and requires release management to keep track of these changes to avoid it. (Some of this risk exists also for 5.12.x branch vs 5.12 branch, if we directly pick from dev to 5.12.x) > >> (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. > > 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 <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 -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
