[Development] Allow to do parallel integration (was: Proposal: New branch model)

Jedrzej Nowacki Jedrzej.Nowacki at qt.io
Wed Jan 30 13:38:46 CET 2019

On Wednesday, January 30, 2019 11:48:40 AM CET Allan Jensen wrote:
> On Wednesday, 30 January 2019 11:19:07 CET Edward Welbourne wrote:
> > Jedrzej Nowacki (30 January 2019 11:08)
> > 
> > > Mårten pointed out that we can check for conflicts up front. Not only
> > > against HEAD of the target branch, but also against all build branches.
> > > That is even nicer as there is no need to start a job that would likely
> > > to be rejected at the end.
> > 
> > That'll only find VC-level conflicts.
> > It's no help in finding the kinds of breakage that only testing reveals.
> > It'll also sometimes lead to rejecting a change needlessly, because the
> > already-integrating branch it conflicts with is about to fail its testing.
> > Still, I guess restaging a little later can fix that ...
> We could do speculative merging. Guess if the previous commit will merge on
> not, and stage the following commit based on that guess. Or stage two
> versions of the next commit, one for success of the previous and one for
> failure. That latter would use 3x the VMs for 2x the throughput.
> 'Allan

We could. In such case we do not allow regressions, but we waste ~50% of 
speculative builds. I believe that would be much better accepting the risks, 
the throughput maybe N times higher, when N is count of parallel build 
branches. In the end reverts are just one click. Btw. after revert coin will 
likely detect that the revision was build and it would just use cached 
results, so it may even avoid running tests.


More information about the Development mailing list