705291 - Graphs-new should not be timeline based but changeset landings based

Status: RESOLVED DUPLICATE of bug 688534

(Webtools Graveyard :: Graph Server, defect)

Description

[Armen [:armenzg]]

I've been trying to hunt regressions for the last few weeks. This bug prevents me from doing the work properly for the following reasons:
* changeset A lands
* changeset B lands after A (changeset B has a regression)
* job B finishes before A
* job B posts to graph before post for job A

This happens constantly and blurs the line specially when merges are happening all the time from mozilla-inbound.

Changing to what I propose also needs to handle that certain changesets do not have coverage. This is, change X and change Y are merged together and only change Y is posted. change X should be shown on the graph but show no associated graph post. This would help to discover lack of coverage and speed up requesting builds for those changes that have missing coverage.

Making this change also adds a complexity when comparing two or more branches.
If changes f1, f2 and f3 happen in branch F in between changes g1 and g2 for branch G then it should be represented like g1, f1, f2 and f3.

To make it explicit, there is no need to separate changes based on how far apart they actually happened. The X coordinates should be have a changeset per increment. It should not matter if change B happened 20 hours after change A or just 20 minutes. They should be evenly spaced.

This also implies if several talos jobs are requested for the same changeset then we would have several posts on the same X coordinate since they are linked to the change rather than to the time they happened. If you want we can make this column a little wider to fit all changes horizontally rather than on the exact same coordinate.

Please feel free to ask me to gather feedback or meet to discuss questions or work on drafts.

A-team, releng, I assume our tools should not be affected as this is the visualization part but perhaps our tools should also be aware of this changeset sorting concept rather than timestamp sorting.