1: Each colored block in a table corresponds to an email sent to dev-tree-management. Whitespace is assumed to mean that there was no significant change for that platform over whatever range of changesets gets covered, given the lack of emails to dev-tree-management.

2: Correlating this with the graphserver would be useful. Even just letting the individual changes link back to graphserver output.

3,4,5,7,9: Yeah, the UI could use some work/more information.

6: I am not that competent of an Ajax-y programmer. (Yet?)

8: Yes to the first part; I don’t understand the second question.

So I’ll ask questions and make a bunch of requests to try to slow you down:

1. Is the changeset range a rollup, or the finest available granularity? (As in, does each range correspond to a interval between talos runs?)

2. I’d like to be able to look at the table to find an interesting platform, then click on the platform heading to show a graph of just that platform over time. Maybe that points to the graph server with appropriate parameters? (I haven’t looked at the graph server in ages, ever since I gave up on interpreting whatever the heck its mass of lines was trying to show me.)

3. I want to be able to feed in a changeset hash and have it highlight the row containing it on all graphs. (“Did changeset X break/improve things?”)

4. I’d like push datetime ranges for the rev ranges.

5. DD/MM/YYYY sucks almost as much as MM/DD/YYYY. Pretty please use YYYY/MM/DD?

6. I sort of want to be able to star the big jumps (comment on them with any known explanation.) But that raises all kinds of issues

7. Is the final row a percent? If so, add a percent sign so I don’t have to wonder.

8. White gaps mean talos was not run for anything in that changeset range? Then what does a multi-row cell just after a white gap mean?

9. Could you add a changeset count to the rows? Just to have a feel for whether it was a merge or individual change. I suppose it would be more direct to label merges vs regular commits (vs backouts?)