Actually (though I've been busy implementing other things), I've been planning a somewhat different way to solve the scalability problems that I called "auto rollup."
* Approved Pull Requests (PRs) are pushed to the end of a queue as normal. They are marked as elligible for auto-rollup by default. * If the topmost item in the queue is marked as not elligible for auto rollup, then it is run as normal. If it succeeds then it goes into master. If it fails and it contains more than one PR, then it is split in half, and the halves are pushed to the back of the queue and marked as inelligible for auto-rollup. If it fails and it only contains a single PR, then that PR is reported broken. * If the topmost item in the queue is elligible for auto-rollup, then it and anything else in the queue that is elligible is merged into a single queue item with all the PRs. Since this is equivalent to a binary search, it should have a worst-case complexity factor of O(F*log(N)), where F is the number of failing pull requests and N is the number of pull requests in total. When F is zero, this model achieves constant time over N. On Thu, Aug 4, 2016 at 8:41 AM Jack Moffitt <j...@metajack.im> wrote: > > My point is that I believe it's possible to create a setup doing full > > pre-commit testing -- with all the advantages it brings over post-commit > > testing -- while avoiding the scalability problems of the existing setup > > is Servo. > > It depends what you mean by scalability. Doesn't pipelining the tests > require # PRs in queue * builders number of builders? This seems to > trade time for machines by optimistically assuming all previous PRs > passed tests. > > jack. > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
