[Webkit-unassigned] [Bug 35460] EWS should test patches with r+

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=35460





--- Comment #9 from Adam Barth <abarth at webkit.org>  2010-10-15 09:37:41 PST ---
> 1.  Add a page to queues.webkit.org, which will expose the last status message across all queues for a single patch. (machine readable.  The query probably has to be "all status messages matching this patch id, limited to the last 1000" and then we'll filter for just one of each.  I don't think GQL can do unique/group style queries).

This page isn't needed.

> 2.  Add a page to queues.webkit.org which allows a bot (or a user) to submit any attachment id to all EWSes (using checkboxes in the form).  (Careful to limit it only to EWSes, but otherwise no error checking.)

This requires the server to know the global list of all EWS.  It should just add the attachment to the datastore as "an attachment that once upon a time had an r?".

> 3.  Have an EWS feeder pull down all r? patches (and at a less frequent interval, all r+ patches).

There's no need to poll for the r+ patches.  If the patch is only up for review for 30 seconds, its ok if we miss it.

> 4.  The EWS feeder will submit each patch to EWSes after checking the last-status page.  only submitting it to EWSes which either have no status, or the last status is RETRY (this allows a user to submit a patch again after PASS/FAIL, but the bot to only submit when RETRY).

It doesn't need to check the last-status page.  It can cache things in memory to avoid spamming the server all the time.  The server can do the final dedup.

> 5.  Change /next-patch to remove the patch from the active-work-items, or add a new /patch-completed action to do so.

In the first phase, we shouldn't need to worry about changing the mechanism by which the EWS bots avoid processing the same patch again.  We can support multiple bots in a separate patch.

> 6. Remove the update-work-items code from the EWS bots.  "Submitting" is a non-destructive action.  Never to we write to the server the entire list of patches to process.  We only add with submit-to-ews and remove with /patch-completed.

Ok.  We want to make sure we can still generate the #n parts of the status bubbles, but it sounds like we'll have a way to do this from the other data.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.