[Development] Proposal: New branch model

[Lars Knoll]

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 <perezmeyer at gmail.com<mailto:perezmeyer at gmail.com>> wrote:

El dom., 10 feb. 2019 05:44, Sune Vuorela <nospam at vuorela.dk<mailto:nospam at 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 at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190215/82d1793c/attachment.html>