Since there is no longer a b2g perf team to watch fxos-perf-alerts@mozilla.org, Dietrich would like perf alerts sent to patch authors of all the Gaia commits in the regression range. We already identify the gaia regression range, so this would just be getting the list of commits in that range, identifying the patch authors, and including those people in the e-mail distribution. We will ignore the gecko commit range for now, since it is often large enough that alerts would be meaningless. Kyle, can you scope this work and determine how difficult it would be to implement?

Please give me the list of "patch authors": At the very least they can be added to the list of emails notified when b2g regressions happen. I will need one person (?Dietrich?) that will work with me to improve them beyond what we have now. We already identify the regression range (both gaia and gecko), so it is only a matter of refining the alerts to suit.

after talking with Mark I now see that the "patch authors" are defined as those writing the patch (of course!) For some reason I read "module owners".

Yes, exactly...you can get this information via git for a given regression range.

We have a few ways we could handle this, but only time this quarter to do one of them: 1 - Send alerts to gaia commit authors in regression range. This won't always be accurate and it's a bit of a pain because we'd have to keep and up-to-date gaia checkout on the alert server to query commit authors. 2 - Send alerts to gaia module owners. We'd have to maintain a mapping of gaia module owners, and tests to modules. 3 - Provide a JSON feed of all B2G alerts, that you could build whatever dashboard you wanted around. In addition to any of the above, we could send alerts to dev.tree-management (like we currently do for Talos alerts), which would make them more visible than the fxos-perf-alerts mailing list. Dietrich, do you have a preference here?

#3 is a fine start, if the feed has bug numbers. Then we can then build something that queries the Bugzilla API to get the emails and send emails that way. Sending to dev.tree-management sounds great.

Can we even get the bug numbers without an up-to-date gaia checkout? It would seem the work for #1 is inevitable; and valuable in other ways too.

Kyle is working on this, but is trying to improve the algorithm so that it can better pinpoint regression ranges. Currently, he feels it may be too noisy to make these e-mails useful. For example, a current alert had this regression range, of 9 commits: https://github.com/mozilla-b2g/gaia/compare/18917f59141b850280c68e551e80dea41e4ac498...9755d24b2ce2af38bb5ff54f9e08f89dce2d9384 Dietrich, would it be useful to send alerts to too many people, or would it be better to continue work on reducing the regression range first?

This is just fine. Back in the olden days, we'd have ranges on Mozilla-central (er, trunk on CVS i mean) of many more check-ins - but having that was WAY better than having no idea at all. And often just a quick visual scan of the range by devs who committed within it is enough to identify the culprit. That can radically impact the time-to-fix, and also help create a visceral connection for the developers to the impact of their landings. I'm hoping that once this is in place we can even post the links to the ranges to places like IRC channels and whole mailing lists, ensuring that regressions get *immediate* attention. (hashtag ittakesavillage)

Any update?

Kyle has been busy migrating Talos data from Datazilla to Treeherder, so we haven't yet produced a JSON feed of B2G alerts. We want to deprecate Datazilla rather soon, and I think James Lal is working on a potential alternate to Datazilla for B2G perf data. If you still are interested in having this done, I suggest setting up a meeting with James, Kyle, Eli and myself to discuss the best way forward.

We are going to stop managing B2G perf in datazilla soon; this work will migrate to the raptor tool being developed by the B2G Automation team.

I don't see how that makes this bug WONTFIX. Changing architecture doesn't change the fact that warning patch authors is a good thing for the health of the project.

This bug isn't an expression of a general requirement, it's a feature request against a specific product which is going away. I agree this is a good thing to have, but it won't take place as part of Datazilla or be implemented by the people that work on it. I recommend talking to Eli and seeing where it would be appropriate to file a new bug.