<div dir="ltr">Oops, my reply is on the m.d.platform thread <a href="https://groups.google.com/forum/#!topic/mozilla.dev.platform/QHdn-ogf8kQ">https://groups.google.com/forum/#!topic/mozilla.dev.platform/QHdn-ogf8kQ</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 14, 2015 at 5:45 PM, Kartikaya Gupta <span dir="ltr"><<a href="mailto:kgupta@mozilla.com" target="_blank">kgupta@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In general I'm in favour of this proposal, although it will probably<br>
come back to haunt me in the not-too-distant future. That being said I<br>
would like to know what criteria you used to distinguish "reliable"<br>
talos tests from the rest.<br>
<br>
kats<br>
<div><div class="h5"><br>
On Fri, Aug 14, 2015 at 5:26 PM, Vladan Djeric <<a href="mailto:vdjeric@mozilla.com">vdjeric@mozilla.com</a>> wrote:<br>
> The perf team and the A-Team would like to test out a new policy: we want<br>
> to back out patches that cause significant Talos regressions on Windows<br>
> builds. We would like to get developers’ feedback before starting this<br>
> experiment.<br>
><br>
> Why are we doing this?<br>
><br>
> Essentially, we would like more Talos regressions to get fixed and Firefox<br>
> performance to improve. We want to test a 48-hour backout policy because we<br>
> noticed that patch authors often don't fix regressions quickly. If a<br>
> regression sits in the tree for days, it becomes difficult to back out, and<br>
> it becomes much more likely that the regression will end up riding the<br>
> trains to Release by default.<br>
><br>
> Note that we already have a policy of backing out regressions of 3% or more<br>
> if the patch author does not respond at all on the regression bug for 3<br>
> business days. See<br>
> <a href="https://wiki.mozilla.org/Buildbot/Talos/RegressionBugsHandling" rel="noreferrer" target="_blank">https://wiki.mozilla.org/Buildbot/Talos/RegressionBugsHandling</a><br>
><br>
> The new policy is more aggressive. We think a patch that regresses<br>
> performance significantly should be backed out quickly, and re-landed when<br>
> its performance is acceptable.<br>
><br>
> How will the backouts work?<br>
><br>
> The A-Team perf sheriffs will create a Talos regression bug as soon as a<br>
> regression is confirmed using Talos re-triggers. The patch author and<br>
> reviewer will be CC’ed, and if they don’t provide an explanation for why<br>
> the regression is acceptable, the patch will be backed out. The goal is to<br>
> back out unjustified regressions within 48 hours of landing. We’d like to<br>
> give the patch author about 24 hours to reply after the regression bug is<br>
> filed.<br>
><br>
> The A-Team has been working hard on improving the tools for understanding<br>
> Talos regressions (e.g. Perfherder), and we think debugging a Talos<br>
> regression is a much less painful process these days. For example, there is<br>
> now a highly usable view to visualize the comparison between a proposed<br>
> patch against a baseline revision at<br>
> <a href="https://treeherder.mozilla.org/perf.html#/comparechooser" rel="noreferrer" target="_blank">https://treeherder.mozilla.org/perf.html#/comparechooser</a><br>
><br>
> Will all regressions get backed out?<br>
><br>
> No. Only regressions of 10% or more, on reliable Talos tests, on Windows,<br>
> will face automatic backouts during this trial period. Given historical<br>
> trends, we are anticipating about one backout per week.<br>
><br>
><br>
> List of reliable Talos tests: ts_paint, sessionrestore, tp5o_scroll,<br>
> tscrollx, tresize, TART, tsvgx, tp5o<br>
><br>
> How are you testing this new policy?<br>
><br>
> First off, we want developers’ feedback before trialing this new policy.<br>
><br>
> I would like us to collect feedback and then start enforcing the new policy<br>
> sometime next week. You can talk to us on the newsgroups or on #perf. You<br>
> can also reach me directly (my IRC nick is “vladan”).<br>
><br>
> We’ll post our conclusions on the newsgroups after a couple of months of<br>
> enforcing the policy, and then we can all re-evaluate the backout policy<br>
> together.<br>
><br>
> Who will be the perf sheriffs?<br>
><br>
> Joel Maher, Vaibhav Agrawal<br>
</div></div>> _______________________________________________<br>
> dev-platform mailing list<br>
> <a href="mailto:dev-platform@lists.mozilla.org">dev-platform@lists.mozilla.org</a><br>
> <a href="https://lists.mozilla.org/listinfo/dev-platform" rel="noreferrer" target="_blank">https://lists.mozilla.org/listinfo/dev-platform</a><br>
</blockquote></div><br></div>