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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development