Yeah, the problem with that is:
def fetch_patches_from_pending_commit_list(self):
return sum([self._fetch_bug(bug_id).reviewed_patches()
for bug_id in self.fetch_bug_ids_from_pending_commit_list()], [])
which means each EWS bot is going to poll ~90 bugs every 2 minutes.
Fo
On Fri, Sep 24, 2010 at 11:42 AM, Eric Seidel wrote:
> https://bugs.webkit.org/show_bug.cgi?id=35460
>
> On Fri, Sep 24, 2010 at 10:25 AM, Darin Adler wrote:
>> It’s not great that if I review a patch that means it won’t get EWS results.
>> Maybe the EWS could be changed to test out “review+” pa
On Fri, Sep 24, 2010 at 10:59 AM, Adam Barth wrote:
> Eric and I have slowly been making progress on this problem. The
> underlying issue is that there does seem to be a bugzilla query for
*doesn't
> quite the right set of things (Eric knows the details here). To make
> this work, we're shifti
Eric and I have slowly been making progress on this problem. The
underlying issue is that there does seem to be a bugzilla query for
quite the right set of things (Eric knows the details here). To make
this work, we're shifting the list of patches to analyze over to our
AppEngine instance. So fa
If they are r+'ed, there is a big change that they are soon to become
committed, so maybe they should get even more priority?
Kenneth
On Fri, Sep 24, 2010 at 2:25 PM, Darin Adler wrote:
> It’s not great that if I review a patch that means it won’t get EWS results.
> Maybe the EWS could be chang
It’s not great that if I review a patch that means it won’t get EWS results.
Maybe the EWS could be changed to test out “review+” patches once it gets done
with all the “review?” patches?
Is that practical?
-- Darin
___
webkit-dev mailing list
we
6 matches
Mail list logo
