On Wednesday, January 30, 2019 1:55:41 PM CET Allan Jensen wrote: > 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
Not to my knowledge (last 7 days): total percentage Passed 153 47.37% Failed 147 45.51% Cancelled 23 7.12% _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development