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

[Allan Jensen]

On Wednesday, 30 January 2019 13:38:46 CET Jedrzej Nowacki wrote:
> 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.
> 
At the current pass rates it would be a better speculation to assume that the 
other commits do not merge.

'Allan