Bug 41791 – Commit Queue shouldn't sort by oldest modification date

• Component: Tools / Tests
• Status: NEW

[Tony Gentilcore]

The Commit Queue sorts by oldest modification date:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/net/bugzilla.py#L266

This basically means that they are landed by bug ID (i.e. when the issue was opened), rather than by when they were added to the queue. A fairer algorithm would be to order them by when they were added to the queue.

Here's an example showing patches with older lower bug IDs (oldest mod date) being inserted into the start of the queue (instead of behind the patches already in the queue):

Snapshot 1 (11:22AM PST):
#1 60715
#2 60721
#3 60722
#4 60729
#5 60730
#6 60746
#7 60747
#8 60751

Snapshot 2 (11:35AM PST):
+ #1 60320
+ #2 60580
#3 60715
#4 60721
#5 60722
#6 60729
#7 60730
#8 60746
#9 60747
#10 60751

Snapshot 2 (12:37PM PST):
+ #1	59404
#2	60320
#3	60580
#4	60715
#5	60721
#6	60722
#7	60729
#8	60730
#9	60746
#10	60747
#11	60751
+ #12	60755
+ #13	60757

[Eric Seidel (no email)]

Yeah, the problem is we can't figure out when they were added to the queue, w/o learning how to parse the show_history.cgi page (which we eventually need to do anyway).  The problem there is that then we have more reqeuests on bugzilla.

We need to finish moving to the"push" model we had in mind, where we would have one server polling bugzilla and pushing ids to the stauts server for all the queues to use.  Then only one server is polling every 2m (or more frequently) and can make many more requests.

Then again, commit-queue is the only one who would need to do this kind of polling, so it might be OK to move to that before moving to a single-poller model.

[Eric Seidel (no email)]

We could also cache the cq+ time information in a side hash, that would prevent too much polling of show_history.cgi