Re: Proposed changes to Talos (performance) alerting

2016-01-20 Thread Mike Conley
>> >> As Joel mentioned, it's pretty easy to schedule profiling runs for talos >> using trychooser. Scheduling a profiling run as part of the >> regression-filing process is something we could consider doing, if >> there's a broad consensus it would be useful (I'm always wary of putting >> extra

Re: Proposed changes to Talos (performance) alerting

2016-01-19 Thread William Lachance
On 2016-01-18 4:42 AM, Nicolas B. Pierron wrote: I agree, this should be the part of the developer to work that out, but the TS Paint benchmark is out of the knowledge base of JS developers. I feel that the problem is reaching developers with a wording known by the developers. So we have a

Re: Proposed changes to Talos (performance) alerting

2016-01-19 Thread jmaher
> > This is just a raw idea, but maybe this would make more sense to provide a > diff of profiles, and show what decreased / increased. At least this would > make these benchmarks less obscure. > Pushing a before/after patch to try with profiling (note the numbers are not useful) can be done

Re: Proposed changes to Talos (performance) alerting

2016-01-18 Thread Nicolas B. Pierron
On 01/06/2016 10:54 PM, William Lachance wrote: […] thinking that graphserver alerts (and perhaps talos in general?) are "just noise". I think one of the reason might be a miss understanding of the causality. When a modification of the JS engine causes a TS Paint regression, without a clear

Proposed changes to Talos (performance) alerting

2016-01-06 Thread William Lachance
I'd like to propose some changes in how we report and triage Talos alerts. Over the past couple years, Joel Maher (with occasional assistance from myself and others) has taken over the job of triaging and responding to ("sheriffing") Talos regressions. He's done this through a bunch of