Sorry to continue beating this horse, but I don't think it's quite dead yet:
One of the best things we could do to make finding these regressions easier is to never coalesce Talos on mozilla-inbound. It's crazy to waste developer time bisecting Talos locally when we don't run it on every push. Another thing that would help a lot is fixing bug 752002, so people will stop filtering the e-mails. On Thu, Aug 30, 2012 at 6:42 PM, Taras Glek <tg...@mozilla.com> wrote: > Hi, > We had a quick meeting focused on how to not regress Talos. > > > Attendance: Taras Glek, Ehsan Akhgari, Clint Talbert, Nathan Froyd, Dave > Mandelin, Christina Choi, Joel Maher > > > Notes: > * Clint's Automation&Tools team is improving Talos reporting abilities. We > should have much better tools for comparing performance between 2 different > changesets soon. > * Talos is now significantly easier to run locally than it used to be. > Expect blog posts from Joel/Ehsan > * Joel will revisit maintaining Talos within mozilla-central to reduce > developer barriers to understanding what a particular Talos test result > means. This should also make Talos easier to run > > * We will implement a formal policy on Talos impact of merges. > ** focus on perf tracking on inbound, to avoid merge pains > ** We will extend the current merge criteria of last green PGO changeset to > also include "good Talos numbers" > > * Nathan Froyd will look at historical data for the last Firefox nightly > release cycle to come up with threshold numbers for backing out commits > * Joel/Ehsan will look into using mozregression with talos so we can bisect > performance regressions locally. We will also consider doing something > similar on try. > > Taras > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
