[Development] Proposal: New branch model

Jedrzej Nowacki Jedrzej.Nowacki at qt.io
Thu Jan 24 14:31:16 CET 2019

Dnia czwartek, 24 stycznia 2019 10:24:57 CET Allan Sandfeld Jensen pisze:
> On Donnerstag, 24. Januar 2019 10:11:35 CET Volker Hilsheimer wrote:
> > More people working and building against dev helps keep dev more stable
> > (by
> > virtue of discovering breakage sooner), and the proposal encourages more
> > people to work on dev. That can be a good thing.
> No,  it will overload the CI by having all integrations happen on the same
> branch, instead being able to integrate multiple branches at once.

It will overload in what way? Yes, in total we would have more integrations. 
If you look into the statistics (https://testresults.qt.io/grafana/d/
000000024/telegraf-host-metrics) you can see that we have some free resources. 
In general we should not really cross load of 60, but most of the hosts are on 
significantly lower load. I would be more concerned about flakiness, as it means 
that we run more tests, but that is something that we need to fix no matter 

> > Either way, nothing in the proposal prevents us from developing and push a
> > fix for 5.12, and then develop a different fix for dev that we don’t
> > cherry
> > pick into 5.12 or other stable branches. This should be an exception, used
> > in urgent situations where indeed we can’t wait. For those cases, there’s
> > no merge conflict in the first place in the new model (because there’s no
> > merge).
> It is still doing merging the wrong way for no good reason. Even if cherry-
> picking itself wasnt a bad idea. You could just as well commit to the stable
> branch first and then cherry-pick it to the other branches. That way there
> would be no need for cryptic annotations, the branches to pick to would be
> implicit from where the patch first landed. Or even better, you could
> perform a merge to dev on every single commit to the stable branch, or even
> better, only create a merge if there are conflicts, so we don't overload
> the CI on dev.
> 'Allan

If you cherry-pick the opposite way, the risk of regression is; higher, 
because of one time contributions (I'm using 5.9 I do not care about other 
releases, so I will not solve the merge conflicts or baby sit the changes) or 
because of lack of interest (oh, that is simply re-write I will not do it) or 
because just a mistake (oh it is still in my gerrit dashboard). In my opinion 
regressions are much worse then, a missing fix in an older branch.


More information about the Development mailing list