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
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.
We could also cache the cq+ time information in a side hash, that would prevent too much polling of show_history.cgi