Bug 41791 - Commit Queue shouldn't sort by oldest modification date
Summary: Commit Queue shouldn't sort by oldest modification date
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-07 12:46 PDT by Tony Gentilcore
Modified: 2010-09-01 16:36 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tony Gentilcore 2010-07-07 12:46:48 PDT
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
Comment 1 Eric Seidel (no email) 2010-07-07 13:18:53 PDT
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.
Comment 2 Eric Seidel (no email) 2010-07-07 13:19:41 PDT
We could also cache the cq+ time information in a side hash, that would prevent too much polling of show_history.cgi