Re: Making try faster for debugging intermittents

On 2016-07-01 06:10 AM, Mike Hommey wrote: On Fri, Jul 01, 2016 at 03:07:43PM +1000, Xidorn Quan wrote: On Fri, Jul 1, 2016 at 1:02 PM, Karl Tomlinson wrote: William Lachance writes: As part of a larger effort to improve the experience around debugging intermittents,

Re: Making try faster for debugging intermittents

On 2016-07-01 6:10 AM, Mike Hommey wrote: > > One thing that might be helpful is enabling running only tests on > > try with a designated build that has already been created. > > > > Often tests are modified to add logging, after which the same > > build could be run with the new version of the

Re: Making try faster for debugging intermittents

On Fri, Jul 01, 2016 at 03:07:43PM +1000, Xidorn Quan wrote: > On Fri, Jul 1, 2016 at 1:02 PM, Karl Tomlinson wrote: > > > William Lachance writes: > > > > > As part of a larger effort to improve the experience around > > > debugging intermittents, I've been looking at

Re: Making try faster for debugging intermittents

On Fri, Jul 1, 2016 at 1:02 PM, Karl Tomlinson wrote: > William Lachance writes: > > > As part of a larger effort to improve the experience around > > debugging intermittents, I've been looking at reducing the time it > > takes for common "try" workloads for developers (so

Re: Making try faster for debugging intermittents

William Lachance writes: > As part of a larger effort to improve the experience around > debugging intermittents, I've been looking at reducing the time it > takes for common "try" workloads for developers (so that > e.g. retriggering a job to reproduce a failure can happen faster). > Also,

Making try faster for debugging intermittents

As part of a larger effort to improve the experience around debugging intermittents, I've been looking at reducing the time it takes for common "try" workloads for developers (so that e.g. retriggering a job to reproduce a failure can happen faster). Of course, the common advice of "profile