Re: Optimizing what runs on which push

2017-06-02 18:40 GMT-04:00 Ehsan Akhgari : > On 06/02/2017 06:27 PM, Dustin Mitchell wrote: >> >> It could go two ways: >> >> 1. "Just try it" again and see what breaks. This runs extra jobs, but >> has the benefit of finding any accidental bustage added in the fix; or > > At the cost of forcing yo

Re: Optimizing what runs on which push

On 06/02/2017 06:27 PM, Dustin Mitchell wrote: It could go two ways: 1. "Just try it" again and see what breaks. This runs extra jobs, but has the benefit of finding any accidental bustage added in the fix; or At the cost of forcing you filter through which oranges are your fault and which ones

Re: Optimizing what runs on which push

It could go two ways: 1. "Just try it" again and see what breaks. This runs extra jobs, but has the benefit of finding any accidental bustage added in the fix; or 2. "try this" listing the M jobs that failed (or some simpler-to-write superset like "all chunks of OS X debug mochitest-chrome"). It'

Re: Optimizing what runs on which push

I haven't really read the thread in too much detail so I apologize if what I'll say below is silly or covered elsewhere, but since there seems to be a proposal around replacing the try syntax with machines figuring out what jobs are needed for a push (presumably based on what changed in the pus

Re: Optimizing what runs on which push

I wrote up https://docs.google.com/document/d/1kEEUC3ETCIerOxYDoRRZSEFspunJgU331CX2wwkFZ_8/edit It's not a particularly ambitious text, aiming to capture a consensus rather than propose something new. It's also worth repeating that this is not a proposal for a big new project, but a design strat