Open Bug 1569018 Opened 5 years ago Updated 2 years ago

Graphs of try vs try pushes show irrelevant comparison points


(Tree Management :: Perfherder, enhancement, P3)



(Not tracked)


(Reporter: sfink, Unassigned)


(I'm going to file a collection of bugs related to this usage scenario, so some of this will be repeated.)

Very common usage scenario: I push my patch to try with --rebuild 7. Then I make a dummy patch against my parent revision (typically from 2-3 weeks ago, at least) and push it to try with --rebuild 7 as a baseline. I want to compare those two to see any resultant changes.


This apparently shows the last 14 days' worth of pushes to the try tree. Two problems with that: (1) those pushes are from all kinds of different things, with different base revisions from a wide array of times; and (2) it is very unclear what it is showing. The left side shows "a11yr opt e10s stylo \ try \ linux64 \ fcefb979eac44d05..." As I'm writing this, I'm realizing that that is probably the tip of the try tree, and then 14 days' worth of previous pushes? Which means it might not even include either of my pushes at all, if they are older than the selected time range?

This bug is about the set of graphed revisions it is choosing. I suggest for a try push that mozilla-central from 14 days around the time of the base revision would be more useful than showing the try tree. Pushes from the try tree, other than those I have requested to be compared, are pretty much never what I want to see. I know that the try tree could be used for pushes from any branch, so mozilla-central might not be the best choice. But I would prefer it to show nothing rather than the weirdo try results. Or at least, it could show only the two revisions I have requested, no matter what their timestamps are. At least that way, it would be more obvious that I should select my own "backdrop" repo rather than try to make sense of what it shows by default.

Type: defect → enhancement
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.