They've also helped me on occasion. I get enough bug spam already that even
in the worst case, I don't find the notices all that obtrusive. More useful
messages would be nice though.
J
On Thu, Sep 23, 2010 at 10:28 PM, Geoffrey Garen wrote:
> > Does anyone find the sheriffbot bug posts useful
On 09/23/2010 09:25 PM, ext Alexey Proskuryakov wrote:
I'm sorry if this came across as an attack on you. My goal was to
encourage reviewers to ensure that patches have adequate documentation
and test coverage, and that's why I chose to bring this up on the list.
Point taken.
It was my mistake
I've finally gotten a system setup and configured to run as a build
bot for the WinCairo port. Per the instructions in the wiki, I've
filed a bug (https://bugs.webkit.org/show_bug.cgi?id=46360) to add the
configuration to the build system.
Could someone generate an ID/password combination so I co
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
On Fri, Sep 24, 2010 at 8:50 AM, Brent Fulgham wrote:
> I've finally gotten a system setup and configured to run as a build
> bot for the WinCairo port. Per the instructions in the wiki, I've
> filed a bug (https://bugs.webkit.org/show_bug.cgi?id=46360) to add the
> configuration to the build sys
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
Ok. Thanks for your input everybody. I'm going to try to make the
messages more useful.
adam
On Fri, Sep 24, 2010 at 3:49 AM, Jeremy Orlow wrote:
> They've also helped me on occasion. I get enough bug spam already that even
> in the worst case, I don't find the notices all that obtrusive. M
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
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
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
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
I've noticed that the responseArrayBuffer attribute has recently been added
to the XMLHttpRequest-2 specification:
http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-responsearraybuffer-attribute
I was interested to know if anybody was planning on implementing that
attribute soon. If not, I wou
Sent from the wrong email alias...
Begin forwarded message:
> From: webkit-dev-ow...@lists.webkit.org
> Subject: Re: [webkit-dev] Ruby Text Enhancements
> Date: September 24, 2010 1:55:19 PM HST
> To: mader_e...@apple.com
>
> You must be subscribed in order to post to this mailing list.
>
>
>
24.09.2010, в 16:37, Chris Rogers написал(а):
> I was interested to know if anybody was planning on implementing that
> attribute soon. If not, I would like to add this myself.
The key problem to solve is how to not double the memory use of the
XMLHttpRequest object, while not making response
On Fri, Sep 24, 2010 at 5:09 PM, Alexey Proskuryakov wrote:
>
> 24.09.2010, в 16:37, Chris Rogers написал(а):
>
>> I was interested to know if anybody was planning on implementing that
>> attribute soon. If not, I would like to add this myself.
>
> The key problem to solve is how to not double t
With xhr.responseBlob we chose to have the caller decide up front and tell
the xhr object how it would like the response by setting the xhr.asBlob
attribute prior to calling send(). We could do the same with
xhr.asArrayBuffer.
On Fri, Sep 24, 2010 at 5:09 PM, Alexey Proskuryakov wrote:
>
> 24.09
When the prefetch feature was originally added to WebKit, the first
patch (bug 3652), it had a header X-Moz, for backwards compatibility
with Firefox. Currently, when Firefox follows link prefetch requests,
it adds a header "X-Moz: prefetch" to the request. However, before
3652 was landed, we rem
24.09.2010, в 17:31, Gavin Peters (蓋文彼德斯) написал(а):
> - Cost. Why make requests longer than they need to be?
If used correctly, this will make responses longer, too (due to Vary:
X-Purpose). Due to the nature of Vary, it will need to be sent with every
response for the resource, not just t
If we added xhr.asArrayBuffer, what would happen if xhr.asBlob was also set?
Don't we really want something like xhr.loadAsType with different enum
values for text, blob, array buffer, etc.?
On Fri, Sep 24, 2010 at 5:19 PM, Michael Nordman wrote:
> With xhr.responseBlob we chose to have the call
On 24 September 2010 21:27, Alexey Proskuryakov wrote:
>
> 24.09.2010, в 17:31, Gavin Peters (蓋文彼德斯) написал(а):
>
>> - Cost. Why make requests longer than they need to be?
>
> If used correctly, this will make responses longer, too (due to Vary:
> X-Purpose). Due to the nature of Vary, it will
On Sep 24, 2010, at 6:56 PM, Eric Mader wrote:
>> I have prototyped something that seems to more-or-less work. Here's what I
>> did:
>>
>> 1) Changed RenderRubyRun to subclass these methods:
>> virtual int marginTop() const;
>> virtual int marginBottom() const;
>> virtual int marginL
21 matches
Mail list logo
