Re: [webkit-dev] Fwd: Ruby Text Enhancements

[David Hyatt]

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 marginLeft() const;
>> virtual int marginRight() const;
>> 
>> 
>> 2) added these members to RenderRubyRun:
>> mutable bool m_haveHorizontalMargins;
>> mutable int m_leftMargin;
>> mutable int m_rightMargin;
>> 
>> 3) Added this private method to  RenderRubyRun:
>> void getHorizontalMargins() const;
>> 
>> 4) Here's what marginLeft() and MarginRight() look like:
>> int RenderRubyRun::marginLeft() const
>> {
>> getHorizontalMargins();
>> 
>> return m_leftMargin;
>> }
>> 
>> int RenderRubyRun::marginRight() const
>> {
>> getHorizontalMargins();
>> 
>> return m_rightMargin;
>> }
>> 
>> And here's getHorizontalMargins():
>> void RenderRubyRun::getHorizontalMargins() const
>> {
>> if (m_haveHorizontalMargins) {
>> return;
>> }
>> 
>> RenderText* rubyRenderText = static_cast 
>> (rubyText()->firstChild());
>> RenderText* baseRenderText = static_cast 
>> (rubyBase()->firstChild());
>> int rubyLength = rubyRenderText->firstTextBox()->width();
>> int baseLength = baseRenderText->firstTextBox()->width();
>> int leftMargin = RenderBlock::marginLeft();
>> int rightMargin = RenderBlock::marginRight();
>> 
>> if (baseLength < rubyLength) {
>> RenderObject* prevSibling = parent()->previousSibling();
>> RenderObject* nextSibling = parent()->nextSibling();
>> bool prevIsText = prevSibling && prevSibling->isText();
>> bool nextIsText = nextSibling && nextSibling->isText();
>> 
>> // FIXME: handle odd difference?
>> if (prevIsText)
>> leftMargin += (baseLength - rubyLength) / 2;
>> 
>> if (nextIsText)
>> rightMargin += (baseLength - rubyLength) / 2;
>> }
>> 
>> m_leftMargin = leftMargin;
>> m_rightMargin = rightMargin;
>> m_haveHorizontalMargins = true;
>> 
>> }
>> 

It would probably be simpler to just subclass computeLogicalWidth (recently 
renamed from calcWidth) and modify the m_marginLeft and m_marginRight variables 
after calling the base class method.  Then you don't have to add any new member 
variables.

The big problem with building the overhang into margins at the initial 
calculation time, though, is that you may not get a relayout when objects 
around you change, so you won't get an opportunity to adjust your margins when 
that happens.  Your margins are also computed before you've even know what's 
going on the line, so it could be really tricky to have all the information you 
need.

It just doesn't seem like you can deal with all the corner cases without 
integrating right into line layout.  I don't see how else you can know if you 
have adequate available space to actually overhang without knowing what you've 
seen so far on the line and how much space you have left on the line.


>> This method makes several assumptions that I'm not 100% sure are always safe:
>> * That a RenderRuby object holds only 1 RenderRubyRun object.

I believe you can have multiple RenderRubyRuns inside a single RenderRuby.

http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-ruby-element

"The ruby element allows one or more spans of phrasing content to be marked 
with ruby annotations."

>> * That the text for the ruby text and ruby base are always the direct child 
>> of the RenderRubyText and RenderRubyBase object.

I doubt that's a valid assumption.  I assume that you can have a content tree 
of markup underneath a RenderRubyText and a RenderRubyBase, e.g., if you put in 
some  and some .  Anyway, I think you could just ask for the width() of 
the rubyText() and rubyBase() objects themselves rather than drilling down into 
their subtrees.

>> * That the neighboring text is always a direct sibling of the RenderRuby 
>> object.
>> 

Not a valid assumption.  You could have empty spans etc.

>> One enhancement I know is needed is to look at successive neighboring 
>> objects to make sure that there's enough text there that the overhanging 
>> part of the ruby text doesn't overshoot the neighbor(s) as well and bump 
>> into something it can't overlap.
>> 
>> Does this general approach look right?

This is a tough problem.  It seems like you have to get involved in the line 
layout code e.g., findNextLineBreak in order to really do the right thing.  
findNextLineBreak uses an iterator that walks the objects, so it's easier to 
tell what text came before you and what text comes after you.  You can also 
tell whether or not that text will even fit on the line and possibly do the 
margin hacking there.

You may not want to overhang either if the surrounding text has a higher 
ascent, since I assume you don't w

Re: [webkit-dev] X-Purpose on prefetching requests

[蓋文彼德斯]

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 need to be sent with every 
> response for the resource, not just those that are in response to prefetch 
> requests.

I think I might be missing this point.  For the purposes of
prefetching, I think that once you send out a "Vary: X-Purpose"
header, you've basically opted out of permitting prefetching.  Why
wouldn't such a site send out a non-cacheable failure to prefetching
requests?  A 500 or 404 would likely not cause a cache discard, and so
an eventual user navigation will just cause cache validation; but
that's OK: the prefetch wouldn't have resulted in network activity if
the cache was fresh anyway.

Is there another case I'm forgetting or not understanding?  I can see
how this might be different in the "X-Purpose: preview" case, but that
cat's out of the bag.

> Eric has made another good point in Bugzilla - we don't explain the purpose 
> in lots of other cases, from loading into a display:none frame to 
> XMLHttpRequest. Why should Prefetch be all the different?

That I don't have a good answer to; we don't.  For prefetching
browsers traditionally have, but for these cases they haven't.
Prefetching is not all that different than a display:none frame I
suppose.

- Gavin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] XHR responseArrayBuffer attribute

[Chris Rogers]

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 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.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 responseText and responseXML slow.
>>
>> See also: . Do we need
>> both responseBody and responseArrayBuffer?
>>
>> - WBR, Alexey Proskuryakov
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] X-Purpose on prefetching requests

[Alexey Proskuryakov]

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 those that are in response to prefetch 
requests.

Eric has made another good point in Bugzilla - we don't explain the purpose in 
lots of other cases, from loading into a display:none frame to XMLHttpRequest. 
Why should Prefetch be all the different?

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] X-Purpose on prefetching requests

[蓋文彼德斯]

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 removed this.  The "X-Moz" header is pretty ugly,
it has a very bad name.

I felt a bit unsatisfied about this, so today I circled back and
landed a patch to cause WebKit, when following prefetches, to send an
"X-Purpose: prefetch" header, which is modelled closely on the
"X-Purpose: preview" header that is sent by Safari when it does its
preview generating loads (for those pictures of websites you see on
the new tab screen).  That patch is in bug 46529.  I've also started a
discussion in the HTTPbis working group about the three incompatible
methods of notification that exist (X-Moz, X-Purpose, and do nothing),
to see if a new header "Purpose" makes sense.

The X-Purpose patch was controversial though; so Alexey Proskuryakov
suggested we start a discussion in the mailing list.

Right now, as I see it (and please chime in with what I'm missing),
points in favour of sending X-Purpose are:

 - Conformity.  Existing browsers that do prefetching/previewing
notify servers, WebKit browsers should follow this.

 - Differentiation.  Allows some kinds of differential treatment.  A
heavily loaded server may not want to serve prefetches, and 500 them.
Some servers today 404 all X-Moz requests; while I think that's a
shame, it is good to let people opt out of a feature.

 - Statistics.  Server authors may wish to distinguish the origins of
their traffic; although of course this is tricky, since prefetch loads
are not always viewed and not always ignored.  (send Cache-Control:
must-revalidate) to prefetch requests, and you'll accurately know
about uses, although at some cost in latency for your users.

- Monitoring.  Perhaps your web monitoring software or network
operations department would like to know
the difference between user navigation, and browser-initiated navigation.

However, against X-Purpose, we have:

 - Acceptance.  We want prefetching to succeed, and this header will
promote opt-out.  Besides, opt-out after getting the request is slow
anyway.

 - Cost.  Why make requests longer than they need to be?

 - Dangerous.  If people vary content based on this header, they
could cause all sorts of caching troubles (for instance a proxy might
cache a 404 from a server that's differentiating traffic).

What do people think?  From I think we should follow existing
practice, and send the header.  I don't think the header cost is very
big, and I am not sure that caching 404s is defensible anyway.  Lots
of headers shouldn't be used to mutate content; this is not new.

Thoughts?

- Gavin


For the original landing of prefetching, see:
https://bugs.webkit.org/show_bug.cgi?id=3652

For this new bug, see: https://bugs.webkit.org/show_bug.cgi?id=46529
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] XHR responseArrayBuffer attribute

[Michael Nordman]

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.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 responseText and responseXML slow.
>
> See also: . Do we need both
> responseBody and responseArrayBuffer?
>
> - WBR, Alexey Proskuryakov
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] XHR responseArrayBuffer attribute

[Eric Uhrhane]

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 the memory use of the 
> XMLHttpRequest object, while not making responseText and responseXML slow.
>
> See also: . Do we need both 
> responseBody and responseArrayBuffer?

responseBody is the name in the XHR2 spec as of right now, but the
discussion at 
http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/1019.html
suggests that it will end up as responseArrayBuffer, so we probably
only need the latter.

Eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] XHR responseArrayBuffer attribute

[Alexey Proskuryakov]

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 responseText and responseXML slow.

See also: . Do we need both 
responseBody and responseArrayBuffer?

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Fwd: Ruby Text Enhancements

[Eric Mader]

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.
> 
> 
> From: Eric Mader 
> Subject: Re: [webkit-dev] Ruby Text Enhancements
> Date: September 24, 2010 1:55:15 PM HST
> To: Roland Steiner 
> Cc: David Hyatt , WebKit Development 
> , Yasuo Kida 
> 
> 
> 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 marginLeft() const;
> virtual int marginRight() const;
> 
> 
> 2) added these members to RenderRubyRun:
> mutable bool m_haveHorizontalMargins;
> mutable int m_leftMargin;
> mutable int m_rightMargin;
> 
> 3) Added this private method to  RenderRubyRun:
> void getHorizontalMargins() const;
> 
> 4) Here's what marginLeft() and MarginRight() look like:
> int RenderRubyRun::marginLeft() const
> {
> getHorizontalMargins();
> 
> return m_leftMargin;
> }
> 
> int RenderRubyRun::marginRight() const
> {
> getHorizontalMargins();
> 
> return m_rightMargin;
> }
> 
> And here's getHorizontalMargins():
> void RenderRubyRun::getHorizontalMargins() const
> {
> if (m_haveHorizontalMargins) {
> return;
> }
> 
> RenderText* rubyRenderText = static_cast 
> (rubyText()->firstChild());
> RenderText* baseRenderText = static_cast 
> (rubyBase()->firstChild());
> int rubyLength = rubyRenderText->firstTextBox()->width();
> int baseLength = baseRenderText->firstTextBox()->width();
> int leftMargin = RenderBlock::marginLeft();
> int rightMargin = RenderBlock::marginRight();
> 
> if (baseLength < rubyLength) {
> RenderObject* prevSibling = parent()->previousSibling();
> RenderObject* nextSibling = parent()->nextSibling();
> bool prevIsText = prevSibling && prevSibling->isText();
> bool nextIsText = nextSibling && nextSibling->isText();
> 
> // FIXME: handle odd difference?
> if (prevIsText)
> leftMargin += (baseLength - rubyLength) / 2;
> 
> if (nextIsText)
> rightMargin += (baseLength - rubyLength) / 2;
> }
> 
> m_leftMargin = leftMargin;
> m_rightMargin = rightMargin;
> m_haveHorizontalMargins = true;
> 
> }
> 
> This method makes several assumptions that I'm not 100% sure are always safe:
> * That a RenderRuby object holds only 1 RenderRubyRun object.
> * That the text for the ruby text and ruby base are always the direct child 
> of the RenderRubyText and RenderRubyBase object.
> * That the neighboring text is always a direct sibling of the RenderRuby 
> object.
> 
> One enhancement I know is needed is to look at successive neighboring objects 
> to make sure that there's enough text there that the overhanging part of the 
> ruby text doesn't overshoot the neighbor(s) as well and bump into something 
> it can't overlap.
> 
> Does this general approach look right?
> 
> Regards,
> Eric Mader
> 
> On Sep 22, 2010, at 12:59 PM, Eric Mader wrote:
> 
>> 
>> On Sep 21, 2010, at 7:16 PM, Roland Steiner wrote:
>> 
>>> Hi Eric, 
>>> 
>>> comments inline:
>>> 
>>> On Wed, Sep 22, 2010 at 6:57 AM, Eric Mader  wrote:
>>> 
>>> On Sep 20, 2010, at 9:52 PM, Roland Steiner wrote:
 Oh vey, that's ambituous! :)  There's so many corner cases I foresee on 
 this one that I was just too happy to postpone it when we originally 
 discussed to leave out CSS3 ruby stuff from the initial implementation, 
 which is purely based off HTML5 - including supporting multiple base/text 
 pairs within a single ruby, and line-breaking within the ruby.
>>> Yes, it's a bit scary. ;-) I don't think I could implement the whole thing 
>>> at once, so I'm looking at doing a partial implementation. Maybe the first 
>>> round would only check to be sure that the neighboring blocks aren't  
>>> blocks.
>>> 
>>> I would actually suggest cutting it down further and at first doing it only 
>>> where the neighbor is plain text - this should still catch 90% of the cases 
>>> where you'd want overhang and should vastly reduce the corner cases. You 
>>> can verify and compute this rather easily when layouting the ruby, and 
>>> you'd not need to worry about different glyph heights of neighboring inline 
>>> elements, or about replaced elements interfering. Overhang would be 
>>> basically be the minimum of: maximum overhang, or length of neighboring 
>>> text run, or available/remaining space on the line. The latter factor may 
>>> also cause you to need to break the ruby or move it to the next line 
>>> altogether.
>> 
>> I'll look at this idea too. What do I need to do to find the neighboring 
>> inline elements?
>> 
>>> I'm looking at us

[webkit-dev] XHR responseArrayBuffer attribute

[Chris Rogers]

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 would like to add this myself.

Regards,
Chris Rogers
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Have EWS compile patches that are review+ once it is done with the ones that are review?

[Adam Barth]

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.
For each bug, it's going to hit the bug page and the attachment page
for a total of 16 queries per second...

IMHO, we're better off moving the list of patches to process to
AppEngine.  In that model, we'll have one query every thirty seconds
on bugs.webkit.org for the whole EWS, no matter how many bots we have.

Adam


On Fri, Sep 24, 2010 at 11:44 AM, Eric Seidel  wrote:
> 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+” patches once 
>>> it gets done with all the “review?” patches?
>>>
>>> Is that practical?
>>>
>>>    -- Darin
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Have EWS compile patches that are review+ once it is done with the ones that are review?

[Eric Seidel]

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+” patches once it gets 
>> done with all the “review?” patches?
>>
>> Is that practical?
>>
>>    -- Darin
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Have EWS compile patches that are review+ once it is done with the ones that are review?

[Adam Barth]

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 shifting the list of patches to analyze over to our
> AppEngine instance.  So far, we've moved the commit-queue to this
> model, which lets us run three instances of the commit-queue in
> parallel, making it more of a "commit-cluster."
>
> Moving the EWS over to this model is probably one or two days more
> work.  Hopefully that should be done sometime next week.
>
> Adam
>
>
> 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+” patches once it gets 
>> done with all the “review?” patches?
>>
>> Is that practical?
>>
>>    -- Darin
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Have EWS compile patches that are review+ once it is done with the ones that are review?

[Adam Barth]

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 far, we've moved the commit-queue to this
model, which lets us run three instances of the commit-queue in
parallel, making it more of a "commit-cluster."

Moving the EWS over to this model is probably one or two days more
work.  Hopefully that should be done sometime next week.

Adam


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+” patches once it gets 
> done with all the “review?” patches?
>
> Is that practical?
>
>    -- Darin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Disable sheriffbot bug posts?

[Adam Barth]

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.  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?  My sense is that
>> > they're too noisy because of flaky tests and large blamelists.  I'm
>> > inclined to turn them off unless someone else is finding them useful.
>>
>> FWIW, they've helped me on occasion and spammed me on occasion.
>>
>> Typically, I don't mind the spam too much because it comes after the last
>> meaningful post in the bug, so it doesn't take too much cognitive load to
>> ignore it when necessary.
>>
>> Geoff
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Have EWS compile patches that are review+ once it is done with the ones that are review?

[Kenneth Rohde Christiansen]

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 changed to test out “review+” patches once it gets 
> done with all the “review?” patches?
>
> Is that practical?
>
>    -- Darin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



-- 
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org

http://codeposts.blogspot.com ﹆﹆﹆
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Request to add Build Bot

[Martin Robinson]

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 system.

This will be a great help to those of us working on the Cairo port!

-Martin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Have EWS compile patches that are review+ once it is done with the ones that are review?

[Darin Adler]

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
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Request to add Build Bot

[Brent Fulgham]

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 could complete
the setup and try to get the bot harnessed to the build system?

Thanks!

-Brent
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [webkit-changes] [68146] trunk/WebCore

[Andreas Kling]

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 to not ask for more documentation and test coverage in 
the patch. It won't be repeated.


Thanks for keeping an eye out :-)

-Kling
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Disable sheriffbot bug posts?

[Jeremy Orlow]

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?  My sense is that
> > they're too noisy because of flaky tests and large blamelists.  I'm
> > inclined to turn them off unless someone else is finding them useful.
>
> FWIW, they've helped me on occasion and spammed me on occasion.
>
> Typically, I don't mind the spam too much because it comes after the last
> meaningful post in the bug, so it doesn't take too much cognitive load to
> ignore it when necessary.
>
> Geoff
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev