Re: [webkit-dev] Review Queue

[Eric Seidel]

We're down to 30 bugs:
https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F

With 36 patches total:
curl -s "https://bugs.webkit.org/request.cgi"; | grep PDT | wc -l

15 of those are Gtk-only bugs.  Need some help from the Gtk reviewers
on this one.

Thanks again to those who have pitched in so far.

-eric

On Sat, May 23, 2009 at 12:20 AM, Eric Seidel  wrote:
> Reviewed more before bed.  We're down to:
>
> https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F
> 50
>
> and
>
> curl -s "https://bugs.webkit.org/request.cgi"; | grep PDT | wc -l
> 61
>
> respectively.
>
> Still awful, but much much better than yesterday.
>
> -eric
>
> On Fri, May 22, 2009 at 7:40 PM, Maciej Stachowiak  wrote:
>>
>> On May 22, 2009, at 2:19 AM, Eric Seidel wrote:
>>
>>> Update:  We're down to 74 patches now.
>>>
>>> Thanks especially to Maciej for all his reviewing this evening:
>>>
>>> curl -s "https://bugs.webkit.org/request.cgi"; | grep PDT | wc -l]
>>> 74
>>>
>>> Still a long way to go.
>>
>> FWIW I prefer this query, which counts by bug and gives a count of 57:
>>
>> https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F
>>
>> It looks like about half the remaining bugs are Qt or Gtk specific, and
>> likely need someone who is expert on those ports to look at them. I don't
>> feel comfortable reviewing things that affect Qt or Gtk APIs especially.
>>
>> - Maciej
>>
>>>
>>>
>>> -eric
>>>
>>> On Fri, May 22, 2009 at 12:27 PM, Eric Seidel  wrote:

 Our review process seems to be failing.  As a reviewer, let me extend
 my apologies to the WebKit community as I am part of this failure.

 We have over 100 patches in the review queue at the moment:
 http://webkit.org/pending-review

 I've started going through the list and reviewing what patches I can.
 I'm also marking r- all patches I can't review which have had no
 comments in the last 2 weeks.

 -eric

>>> ___
>>> 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] Browser issue with multiple tabulators

[Jeremy Orlow]

This is _exactly_ the use case SessionStorage was developed for.  :-)

On Fri, May 22, 2009 at 2:41 PM, Darin Adler  wrote:

> I believe HTML 5’s sessionStorage is intended to resolve this issue.
>
>-- 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] SharedWorkers alternate design

[Jeremy Orlow]

On Fri, May 22, 2009 at 2:25 PM, Drew Wilson  wrote:

> Following up on this, I had a question about the best way to enable the
> implementation of SharedWorkerRepository to vary for different platforms.
> I'd like to provide a default WebKit implementation, but on Chromium we'll
> want to provide an implementation that proxies shared worker operations to
> the browser process - it is unlikely that the two implementations will share
> very much (any?) code.
>
> The current design just defines SharedWorkerRepository as an interface,
> then has a platform-specific static factory which returns an instance of
> this class - the idea is that I'd provide a default WebKit implementation
> (called SharedWorkerProxyImpl.cpp?), then Chromium (or other platforms that
> want their own implementation) can provide their own factory method and
> implementation (for an example of this, see WorkerContextProxy::create() in
> WebCore/worker/WorkerMessagingProxy.cpp.
>
> Is this an acceptable approach? Other approaches I've seen either scatter
> ifdefs around in header files (see KURL.h for an example) which seems
> non-ideal for our case which won't have any shared code, or to have separate
> platform-specific subdirectories, but I'm not certain what the naming
> convention is for a directory that contains " but chromium>".
>
> I think the interface + static factory approach is the cleanest,


This is the gist of what I'm planning for LocalStorage and I believe what
Michael's planning for AppCache.  At least in my case, I think I'll be able
to share a substantial amount of code by running the backend of the code in
the chromium browser process.


> but I've gotten the impression that the use of virtual functions to vary
> implementations per-platform is frowned upon in WebKit. Any advice for me?
>
> -atw
>
>
>
>
> On Fri, May 22, 2009 at 1:20 PM, Kenneth Christiansen <
> kenneth.christian...@openbossa.org> wrote:
>
>> I believe Qt uses instance() in this situation.
>>
>> > Sadly we have not yet found a good verb for the common "get or create"
>> > idiom.
>>
>> Cheers.
>> Kenneth
>>
>
>
> ___
> 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] Browser issue with multiple tabulators

[Darin Adler]

I believe HTML 5’s sessionStorage is intended to resolve this issue.

-- Darin

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

Re: [webkit-dev] SharedWorkers alternate design

[Peter Kasting]

On Fri, May 22, 2009 at 12:30 PM, Darin Adler  wrote:

> Sadly we have not yet found a good verb for the common "get or create"
> idiom.


My own code uses "createObjectIfNeeded()" and similar variants.

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

Re: [webkit-dev] SharedWorkers alternate design

[Drew Wilson]

Following up on this, I had a question about the best way to enable the
implementation of SharedWorkerRepository to vary for different platforms.
I'd like to provide a default WebKit implementation, but on Chromium we'll
want to provide an implementation that proxies shared worker operations to
the browser process - it is unlikely that the two implementations will share
very much (any?) code.

The current design just defines SharedWorkerRepository as an interface, then
has a platform-specific static factory which returns an instance of this
class - the idea is that I'd provide a default WebKit implementation (called
SharedWorkerProxyImpl.cpp?), then Chromium (or other platforms that want
their own implementation) can provide their own factory method and
implementation (for an example of this, see WorkerContextProxy::create() in
WebCore/worker/WorkerMessagingProxy.cpp.

Is this an acceptable approach? Other approaches I've seen either scatter
ifdefs around in header files (see KURL.h for an example) which seems
non-ideal for our case which won't have any shared code, or to have separate
platform-specific subdirectories, but I'm not certain what the naming
convention is for a directory that contains "".

I think the interface + static factory approach is the cleanest, but I've
gotten the impression that the use of virtual functions to vary
implementations per-platform is frowned upon in WebKit. Any advice for me?

-atw



On Fri, May 22, 2009 at 1:20 PM, Kenneth Christiansen <
kenneth.christian...@openbossa.org> wrote:

> I believe Qt uses instance() in this situation.
>
> > Sadly we have not yet found a good verb for the common "get or create"
> > idiom.
>
> Cheers.
> Kenneth
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Browser issue with multiple tabulators

[Sebastian Hennebrueder]

Hello,

I am not sure if this is the right place to ask but I would like to make 
Safari developer aware of a problem in most web applications.


The web is intended to be stateless but web application naturally 
require stateful behaviour. The option to append the state (for example 
a shopping cart) as request parameter to every request is not practical. 
The common solution is to create a server session and to store the 
session ID as cookie or request parameter on the client.


The problem with this approach is that cookies are shared across all 
tabulators and as a consequence they share the same session. If I open 
an edit dialog for product foo in tabulator 1 and an edit dialog for 
product bar in tabulator 2 and submit changes in tabulator 1, I will 
actually change product bar instead of the original in tab 1 selected 'foo'.


A solution to this problem could be a tabulator id, which is a random id 
generated for every tabulator and passed as request header. The web 
developer can now safely allow to have multiple windows on the same 
application by slicing his session into tabulator contexts, to store 
data per tabulator id.


I described this in more details in my blog.

http://www.laliluna.de/blog/2009/05/19/browser_feature_request.html

I would appreciate your feedback on this idea. In case this was the 
wrong place to ask Safari developers, I apologize.


--

Best Regards / Viele Gruesse

Sebastian Hennebrueder
---
http://www.laliluna.de

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

Re: [webkit-dev] SharedWorkers alternate design

[Kenneth Christiansen]

I believe Qt uses instance() in this situation.

> Sadly we have not yet found a good verb for the common "get or create"
> idiom.

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

Re: [webkit-dev] SharedWorkers alternate design

[Drew Wilson]

Thanks - I hadn't realized that about WebKit style.

I've updated the interfaces to use different verbs (like
"createWorkerProxy()") or omit the verb entirely where appropriate.

-atw

On Fri, May 22, 2009 at 12:30 PM, Darin Adler  wrote:

> No substantive comment, but a small style comment.
>
> On May 21, 2009, at 4:20 PM, Drew Wilson wrote:
>
>   // Static factory method for getting the correct repository
>> implementation for a given browser
>>  static public SharedWorkerRepository* getRepository();
>>
>
> Generally WebKit does not use the verb "get" to name functions that simply
> return something. Instead for those we simply use a noun.
>
> If there is some real action involved, then we would want to use a verb,
> but not "get". For example, if the function always creates something we can
> use the word create.
>
> Sadly we have not yet found a good verb for the common "get or create"
> idiom.
>
>-- Darin
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SharedWorkers alternate design

[Darin Adler]

No substantive comment, but a small style comment.

On May 21, 2009, at 4:20 PM, Drew Wilson wrote:

  // Static factory method for getting the correct repository  
implementation for a given browser

  static public SharedWorkerRepository* getRepository();


Generally WebKit does not use the verb "get" to name functions that  
simply return something. Instead for those we simply use a noun.


If there is some real action involved, then we would want to use a  
verb, but not "get". For example, if the function always creates  
something we can use the word create.


Sadly we have not yet found a good verb for the common "get or create"  
idiom.


-- Darin

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

Re: [webkit-dev] Webkit JavaScript question

[Zoltan Herczeg]

Hi,

I don't think so. It is not worth to do it on a desktop pc since
interpreter is always slower than JIT. However, the story is different for
embedded systems, when they enter low-memory mode. We made some
experiments before, and it seems possible to switch between jit and
interpreter, but I am not sure that the community is interested in such
features.

Zoltan

>> The last step depends on the architecture (supported or not) and C++
>> compiler directives. If JIT is enabled (see wtf/Platform.h), it always
>> generates machine code. Otherwise an interpreter executes the byte code.
>> A
>> mixed environment (both jit and interpreter) is not yet supported.
>
> Are there plans for that ? Mozilla's TraceMonkey supports triggering
> JIT execution at runtine already, iirc.
>
> --
> --Antonio Gomes


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

Re: [webkit-dev] Webkit JavaScript question

[Darin Adler]

Some of the rationale is in this blog post too .


For example: “We also think we can get a lot more speedups out of the  
JIT through techniques such as type specialization, better register  
allocation and liveness analysis. [...] bytecode is a good  
representation for making many of these kinds of transforms.”


-- Darin

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

[webkit-dev] Webkit Rendered Image

[webkitUser]

Hi,

I have modified the WinLauncher application to dump what it has rendered.

Basically I have plugged in the "createBitmapContextFromWebView" method from
DumpRenderTree Sample, which is supposed to dump a png out of a WebView.

However, I see that the resulting png just has a blank image and not the
rendered contents. Is this expected?

If yes, how can I get an image out of the Webkit rendered contents?

Thanks in Advance,

-- 
View this message in context: 
http://www.nabble.com/Webkit-Rendered-Image-tp23671148p23671148.html
Sent from the Webkit mailing list archive at Nabble.com.

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

Re: [webkit-dev] Webkit JavaScript question

[Zoltan Herczeg]

Hi,

Historical reasons. SF byte code had been implemented a year ago than jit.
SF byte code (interpreter) will never go away, since not all devices
support jit, and it is easier to generate JIT code from SF byte code than
from Abstract Syntax Tree. Perhaps the authors can tell you more about
this decision.

Zoltan

> Thanks.
>
> Can you please help me understand why SquirellFish needs to generate
> squirellFish byte code first before compile it to machine code?
>
> For v8, it "compiles JavaScript source code directly into machine code
> when it is first executed. There are no intermediate byte codes, no
> interpreter." http://code.google.com/apis/v8/design.html#mach_code
>
> Thank you.
>
>
> On Thu, May 21, 2009 at 2:12 PM, Zoltan Herczeg
>  wrote:
>> Hi,
>>
>> The JavaScript engine does 3 steps:
>> 1) Parse JS files
>> 2) Generate SquirellFish byte code (ByteCodeGenerator.h is part of it)
>> 3) Compile SF byte code to machine code by its JIT compiler (optional)
>>
>> The last step depends on the architecture (supported or not) and C++
>> compiler directives. If JIT is enabled (see wtf/Platform.h), it always
>> generates machine code. Otherwise an interpreter executes the byte code.
>> A
>> mixed environment (both jit and interpreter) is not yet supported.
>>
>> Zoltan
>>
>>> Hi,
>>>
>>> Can you please tell me what is the difference between
>>> ByteCodeGenerator.h and JIT.h?
>>>
>>> I assume ByteCodeGenerator is convert a raw .js file into JavaScript
>>> VM opecode and will be executed by Webkit JavaScript VM.
>>> and JIT convert a raw .js file into native machine code and will be
>>> executed by operating system of the browser?
>>>
>>> Is that correct?
>>> If yes, when/how does Webkit decide to use which approach?
>>> ___
>>> 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] Webkit JavaScript question

[tonikitoo (Antonio Gomes)]

> The last step depends on the architecture (supported or not) and C++
> compiler directives. If JIT is enabled (see wtf/Platform.h), it always
> generates machine code. Otherwise an interpreter executes the byte code. A
> mixed environment (both jit and interpreter) is not yet supported.

Are there plans for that ? Mozilla's TraceMonkey supports triggering
JIT execution at runtine already, iirc.

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

Re: [webkit-dev] Notifications API

[John Gregg]

Sure.  We have the following plan for how to handle opt-in:
 - Use of the feature by script, if permission isn't granted to the origin,
should throw an exception, not present permissions UI.  So your insistent
porn site would have no effect on the user.
 - A dialog box asking for permission should only appear in response to a
user gesture like a click.  So in the normal case, an application will
present a user with a link "New: Desktop Calendar Notifications available!
Click here to setup."  And that link will present a prompt from the
user-agent "Do you trust calendar.com?  The site wants to display
notifications on your desktop.  [Yes/No]"  If the user says yes, script
running under that origin will have permission to show desktop
notifications.
- Permission should be removable through a menu which is accessible from the
notification UI itself.

As proposed the permissions policy is somewhat external to WebKit, which
contains the Javascript API layer but not the actual user-visible parts of
the system including UI, permissions flow, and filtering by origin which
will be in Chromium or another user agent.

 -John


On Thu, May 21, 2009 at 11:39 PM, Ian Hickson  wrote:

> On Thu, 21 May 2009, John Gregg wrote:
> >
> > On the security question, a substantial amount of thought has gone into
> > how to prevent unwanted popups (and in general how to control access to
> > HTML5 application features).  We think user opt-in on an origin-basis is
> > the best policy and it's what we plan to do in Chromium; the WebKit
> > interfaces are structured so that the policy is up to the user agent via
> > a NotificationProvider interface.
>
> Could you elaborate on what you mean by "user opt-in"? A prompt or
> "installation" step seems like a poor user experience given that any site
> could start asking for this, and we don't want users to click "yes" to
> make the message go away (consider a porn site that just does "while
> notifications are not allowed, try to notify").
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Webkit profiling on MacOS

[Meryl Silverburgh]

Hi,

Does Webkit have profiling build in on MacOS?
e.g. For each page, I would like to know how much time is spent on
html parsing, css parsing, javascript executing?
And does Webkit work with Valgrind on MacOS? Or it uses other time of
profiling tool on MacOS? e.g. for each page, find out the break down
of memory usage, what is the % for JS, % for CSS, % for html?

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

Re: [webkit-dev] Webkit JavaScript question

[Lucius Fox]

Thanks.

Can you please help me understand why SquirellFish needs to generate
squirellFish byte code first before compile it to machine code?

For v8, it "compiles JavaScript source code directly into machine code
when it is first executed. There are no intermediate byte codes, no
interpreter." http://code.google.com/apis/v8/design.html#mach_code

Thank you.


On Thu, May 21, 2009 at 2:12 PM, Zoltan Herczeg
 wrote:
> Hi,
>
> The JavaScript engine does 3 steps:
> 1) Parse JS files
> 2) Generate SquirellFish byte code (ByteCodeGenerator.h is part of it)
> 3) Compile SF byte code to machine code by its JIT compiler (optional)
>
> The last step depends on the architecture (supported or not) and C++
> compiler directives. If JIT is enabled (see wtf/Platform.h), it always
> generates machine code. Otherwise an interpreter executes the byte code. A
> mixed environment (both jit and interpreter) is not yet supported.
>
> Zoltan
>
>> Hi,
>>
>> Can you please tell me what is the difference between
>> ByteCodeGenerator.h and JIT.h?
>>
>> I assume ByteCodeGenerator is convert a raw .js file into JavaScript
>> VM opecode and will be executed by Webkit JavaScript VM.
>> and JIT convert a raw .js file into native machine code and will be
>> executed by operating system of the browser?
>>
>> Is that correct?
>> If yes, when/how does Webkit decide to use which approach?
>> ___
>> 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] Review Queue

[Eric Seidel]

Reviewed more before bed.  We're down to:

https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F
50

and

curl -s "https://bugs.webkit.org/request.cgi"; | grep PDT | wc -l
61

respectively.

Still awful, but much much better than yesterday.

-eric

On Fri, May 22, 2009 at 7:40 PM, Maciej Stachowiak  wrote:
>
> On May 22, 2009, at 2:19 AM, Eric Seidel wrote:
>
>> Update:  We're down to 74 patches now.
>>
>> Thanks especially to Maciej for all his reviewing this evening:
>>
>> curl -s "https://bugs.webkit.org/request.cgi"; | grep PDT | wc -l]
>> 74
>>
>> Still a long way to go.
>
> FWIW I prefer this query, which counts by bug and gives a count of 57:
>
> https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F
>
> It looks like about half the remaining bugs are Qt or Gtk specific, and
> likely need someone who is expert on those ports to look at them. I don't
> feel comfortable reviewing things that affect Qt or Gtk APIs especially.
>
> - Maciej
>
>>
>>
>> -eric
>>
>> On Fri, May 22, 2009 at 12:27 PM, Eric Seidel  wrote:
>>>
>>> Our review process seems to be failing.  As a reviewer, let me extend
>>> my apologies to the WebKit community as I am part of this failure.
>>>
>>> We have over 100 patches in the review queue at the moment:
>>> http://webkit.org/pending-review
>>>
>>> I've started going through the list and reviewing what patches I can.
>>> I'm also marking r- all patches I can't review which have had no
>>> comments in the last 2 weeks.
>>>
>>> -eric
>>>
>> ___
>> 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] Review Queue

[Gustavo Noronha]

On Thu, 2009-05-21 at 21:41 -0700, Maciej Stachowiak wrote:

> I discussed the review backlog with Mark Rowe earlier, and we came up
> with another idea that may help. This would be to categorize the
> review queues. Perhaps we could get bugzilla to show a separate review
> queue per component. So for example there would be queues for "CSS",
> "JavaScriptCore", "WebKit Qt", etc. Then we could assign specific
> people to be responsible for that queue. That doesn't mean these are
> the only people who can review, but we would know who to badger if
> certain queues get backlogs.

This would rock. I have my own bugzilla search to try to find GTK+-only
review requests. It's not very reliable, though. Having this correctly
categorized in the review queue itself would be much better.

See you,

-- 
Gustavo Noronha 
GNOME contributor

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

Re: [webkit-dev] Review Queue

[Nikolas Zimmermann]

Am 22.05.2009 um 06:41 schrieb Maciej Stachowiak:



On May 21, 2009, at 9:18 PM, Ojan Vafai wrote:

It makes no sense to me to r- a patch because reviewers don't have  
time to review it. It put incentive in the wrong place. There are  
other solutions to this problem that put incentive in the right  
place (i.e. with reviewers). I don't necessarily think these are  
good ideas, but I'll throw them out there.


1. If the review queue gets too large, close the tree to commits  
until the queue is at 80% of that too large number.
2. Automate landing commits (e.g. click a button off the commit  
queue) so that it's easier to land commits and keep the commit  
queue small.
3. Give some kind of very visible notice on the waterfall when the  
review queue gets too large (e.g. make the background color of the  
whole page red).
4. Auto-assign reviews that haven't gotten reviewed after two weeks  
to a reviewer and have that person be responsible for reviewing it  
in a timely manner (this gives personal responsibility over the  
queue length instead of the current distributed responsibility).


I'm sure there are a ton of other possible solutions to this  
problem that don't punish people sending patches who have little  
control over this situation. I imagine doing 3 and 4 would make a  
significant difference.


I discussed the review backlog with Mark Rowe earlier, and we came  
up with another idea that may help. This would be to categorize the  
review queues. Perhaps we could get bugzilla to show a separate  
review queue per component. So for example there would be queues for  
"CSS", "JavaScriptCore", "WebKit Qt", etc. Then we could assign  
specific people to be responsible for that queue. That doesn't mean  
these are the only people who can review, but we would know who to  
badger if certain queues get backlogs.


I think this is a very wise idea. If we'd combine this with a "review  
queue supervisor" per component it with certainly help to avoid  
backlogs.
For instance the supervisor could get a mail all two weeks listing the  
patches waiting for review. Either the supervisor takes care of the  
review
or delegates to other reviewers. The idea is that at least someone  
notices the queue is very long. The last times this came up on the  
mailing list
I think it was either Eric or Maciej notifying the crowd about the  
state of the review queue. This definately needs to be changed.


So, you get my voice for creating categorized review queues. The  
positive side-effect is that I don't need to scan long time for  
patches that interesst
me (aka. that I'm qualified for review), but rather get the list of  
patches immediately in a single view.


I think it's great that Eric brought up this topic again, as I think  
we can improve the situation much better with not that much effort.


Have a nice day,
Niko

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

Re: [webkit-dev] Review Queue

[Maciej Stachowiak]

On May 22, 2009, at 2:19 AM, Eric Seidel wrote:


Update:  We're down to 74 patches now.

Thanks especially to Maciej for all his reviewing this evening:

curl -s "https://bugs.webkit.org/request.cgi"; | grep PDT | wc -l]
74

Still a long way to go.


FWIW I prefer this query, which counts by bug and gives a count of 57:

https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F

It looks like about half the remaining bugs are Qt or Gtk specific,  
and likely need someone who is expert on those ports to look at them.  
I don't feel comfortable reviewing things that affect Qt or Gtk APIs  
especially.


- Maciej




-eric

On Fri, May 22, 2009 at 12:27 PM, Eric Seidel  wrote:

Our review process seems to be failing.  As a reviewer, let me extend
my apologies to the WebKit community as I am part of this failure.

We have over 100 patches in the review queue at the moment:
http://webkit.org/pending-review

I've started going through the list and reviewing what patches I can.
I'm also marking r- all patches I can't review which have had no
comments in the last 2 weeks.

-eric


___
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] Review Queue

[Eric Seidel]

Update:  We're down to 74 patches now.

Thanks especially to Maciej for all his reviewing this evening:

curl -s "https://bugs.webkit.org/request.cgi"; | grep PDT | wc -l]
74

Still a long way to go.

-eric

On Fri, May 22, 2009 at 12:27 PM, Eric Seidel  wrote:
> Our review process seems to be failing.  As a reviewer, let me extend
> my apologies to the WebKit community as I am part of this failure.
>
> We have over 100 patches in the review queue at the moment:
> http://webkit.org/pending-review
>
> I've started going through the list and reviewing what patches I can.
> I'm also marking r- all patches I can't review which have had no
> comments in the last 2 weeks.
>
> -eric
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] policyBaseURL and mainDocumentURL

[Adam Barth]

On Thu, May 21, 2009 at 1:39 PM, Adam Barth  wrote:
> If it's really the same thing, maybe we should call it
> firstPartyURLForCookies.  :)

For those of you following along at home, the cleanup is happening in
https://bugs.webkit.org/show_bug.cgi?id=25955

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