Note: We might want to distinguish:
1) Anomalies that can clearly be attributed to a commit (i.e. perf measurements done with single-commit resolution).
2) Anomalies that attribute to a range of commits (maybe including rolls) and the commit in question happens to be in the range.

Indeed, that would be a good addition. Is the API already supporting this?

The API shows the revision range for each anomaly, and gives us a list of all anomalies that have rev in their range. I am guessing to know if an anomaly can be attributed to a single link we could check the range rev-1..rev by filtering the response, but I couldn't find an example where that would return anything yet, so maybe chromeperf doesn't analyze such short revision ranges?

*attributed to a single CL

After some discussions, let's display the data in a table like this. Probably should do a similar thing for CF later on.

Deleted: showAlerts.png 88.7 KB

	showAlerts.png 88.7 KB View Download

Note: to identify anomalies for a single commit (not in range) start_revision and end_revision fields of the response, have the same value

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/infra/infra_internal/+/647e20984b381081b5cbba060cf942fcc2b75a3f

commit 647e20984b381081b5cbba060cf942fcc2b75a3f
Author: Andrea D'Olimpio <adolimpio@google.com>
Date: Mon Aug 28 12:31:14 2017

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/infra/infra_internal/+/9851ff864e4864cdaa0f0ddd4a52f2ed5aa70522

commit 9851ff864e4864cdaa0f0ddd4a52f2ed5aa70522
Author: Andrea D'Olimpio <adolimpio@google.com>
Date: Wed Aug 30 16:19:03 2017

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/infra/infra_internal/+/13951eb537556772b03420a3b5812c089d461468

commit 13951eb537556772b03420a3b5812c089d461468
Author: Andrea D'Olimpio <adolimpio@google.com>
Date: Wed Aug 30 16:35:53 2017

I think this feature is currently in a good enough state. Let's wait for sullivan@'s CL to land in order to see it in real action.

After latest team-internal discussions:

Have three categories:

1.) Alerts directly addressed to the CL (range = 1)
2.) Unaddressed (no issue, not ignored, not invalid) alerts signaling that somebody e.g. the own owning the commit has to act on them. This number should go down over time
3.) All alerts in the range (not sure how useful this really is going to be)

New 3.) Show the addressed alerts (has an issue, not ignored, not invalid) to signal that those alerts are already fed into the perf sheriff pipeline

I like 15. That means every alert vanishing from 2 goes into 3. And invalid and ignored we never show, which is good.

Do we also want to make a distinction for alerts who's bugs are marked fixed?

Re #16: I don't think we should do that right now. Adds more complexity (call Monorail) with non clear value. Let's finish this slice first than think about refining it later.

RE #14 so 2.) is just one column containing only the unaddressed regressions? or do we want 2 cols (improvements, regressions) or a single one that sums them up?

RE #15 does this replace the old category 3 or does it shift it? (do we replace the one with all alerts in range or do we keep it?)

RE #15 does this concern only the alerts associated with a regression?

2.) We want both values in the same design as 1.). I am starting to think that improvements might not be needed at all but I would want to get some feedback on that first.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/infra/infra_internal/+/07ea890955712e3743d65d3d2920ff0b9bd654db

commit 07ea890955712e3743d65d3d2920ff0b9bd654db
Author: Andrea D'Olimpio <adolimpio@google.com>
Date: Thu Sep 07 07:55:02 2017