Lots of good discussions around the proposal from Jedrzej. It seems like this has been inconclusive for the moment. Both cherry-picking and the current model have it’s advantages and disadvantages. One major concern was that we’d overload especially qtbase/dev integrations and this would lead to a complete block in qtbase, As this is a concern already today (it’s really way too difficult to get a change into qtbase), I’d propose that we now first get two other things in place before we consider changes to how we do things here.
The first change is to implement the new module handling (see the ‘Qt modules’ thread). Secondly, we need to change our CI to be able to handle multiple CI runs in parallel for a single repository/branch. This change is something I believe is required in any case (independent of the branching model to make it easier to land changes). That change implies that we can have multiple staging branches that are tested in parallel instead of limiting ourselves to one. If a branch passes it’ll get merged into the target branch (unless there are conflicts). With this approach, we are running a minimal risk that two staging branches that are tested independently are not conflicting code wise, but will together cause an auto test regression somewhere. If that happens, we’ll find out very quickly in any case (because the branch will be blocked for further integrations until this is fixed), so I don’t think this is problematic. There’s also a good chance that a good part of the problems we’re having with merges will go away once we have these two things implemented. So I’d say let’s do those first, see how it goes and then reconsider our branching/merging strategy. Cheers, Lars On 10 Feb 2019, at 21:31, Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com<mailto:perezme...@gmail.com>> wrote: El dom., 10 feb. 2019 05:44, Sune Vuorela <nos...@vuorela.dk<mailto:nos...@vuorela.dk>> escribió: [snip] I'm mostly a casual contributor, mostly dealing with fixes to bugs found in specific releases. I'm doing my fixes in those releases. Because that's where I need them. If I could just then push it and more or less forget about it, that's the thing that would make it easier. This seems to me that I need to move the fix forward to dev, then push it, then backport it. I might not even have a dev build handy. Because I'm basing my work on top of something released. +1. This is the normal case for distributors (distros) and the patches we normally work on. _______________________________________________ Development mailing list Development@qt-project.org<mailto: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
