One fundamental problem with precommit testing the precise commit to be merged is that intermittents are more costly. You either have to hold up the pipeline while you retrigger the intermittent job, or throw away all of the green results you got and try again later. This doesn't scale to that ~600 per-commit CI jobs that we run on mozilla-central, where it's almost unheard of to have an entirely green run with no intermittents at all. The nice thing about combining pre-commit testing of the changesets (but not precise commits) with post-commit testing is that intermittents can be retriggered without holding anything up.
At a higher level: the advantage of the proposed approach (3) is that jives very well with the way TaskCluster and TreeHerder currently work, which makes it a very tractable model upon which to align both mozilla-central and servo/servo. I think we should start with that as a minimum-viable implementation, and then tweak design and algorithms if there are obvious improvements that we can envision. bholley On Thu, Aug 4, 2016 at 12:19 PM, Michael Howell <[email protected]> wrote: > 04.1000 < jgraham> I'm pretty sure every discussion I've ever seen of > commit queues has ended with someone saying "we should binary search on the > queue" > > 04.1000 < jgraham> I'm also pretty sure that zero times so far has anyone > actually implemented that proposal :/ > > On Thu, Aug 4, 2016 at 11:45 AM Jack Moffitt <[email protected]> wrote: > > > > 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." > > > > This is more or less the direction I've thought we'd move in as well. > > Basically try in bigger batches but have blame pinpointing stay the > > same. > > > > It does share one of the same drawbacks as the pipelining proposal, > > which is that in the case that things aren't mostly succeeding by > > default, it makes things slower. That said I think this is worth > > trying. > > > > jack. > > _______________________________________________ > > dev-servo mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-servo > > > _______________________________________________ > dev-servo mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list [email protected] https://lists.mozilla.org/listinfo/dev-servo

