Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?

[Gustavo Sverzut Barbieri]

Guessed so from Qt port... Now we need to do that for both soup and
curl, or write an abstraction for elf with some backend outside webkit

On Saturday, July 24, 2010, Darin Adler  wrote:
> This is a matter for the networking layer in your particular port rather than 
> for WebKit itself. It does not require changes to WebKit. The Mac OS X WebKit 
> networking layer, NSURLConnection, has this feature. It’s done by creating a 
> custom NSURLProtocol object.
>
>     -- Darin
>
>

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] How to register another protocol handler

[Darin Adler]

On Jul 23, 2010, at 9:46 AM, Flávio Ceolin wrote:

> First of all, is this a task for WebCore or the port ?

If I understand your question correctly, the answer is that it’s a task for the 
networking layer, which is port-specific. The Mac OS X WebKit networking layer, 
NSURLConnection, has this feature. It’s done by creating a custom NSURLProtocol 
object.

-- Darin

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

Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?

[Darin Adler]

This is a matter for the networking layer in your particular port rather than 
for WebKit itself. It does not require changes to WebKit. The Mac OS X WebKit 
networking layer, NSURLConnection, has this feature. It’s done by creating a 
custom NSURLProtocol object.

-- Darin

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

Re: [webkit-dev] A Parallel Webkit?

[Adam Barth]

On Fri, Jul 23, 2010 at 5:27 PM, Oliver Hunt  wrote:
> On Jul 23, 2010, at 4:50 PM, Leo Meyerovich wrote:
>>> I wasn't entirely sure what OP was after of if the reply below
>>> adequately addressed his interests.
>>
>> WebKit2 seems to have little to do with taking advantage of parallel 
>> hardware in browser algorithms like lexing, parsing, selectors, JS 
>> compilation, JS execution, layout, DOM interactions, fonts, rendering, etc.
>
> JS execution and DOM manipulation are single threaded, and that thread is the 
> UI thread, this fact cannot be changed.  JS compilation is also done lazily 
> in webkit so we don't ever end up with multiple pieces of code to compile 
> concurrently.

We could potentially do HTML parsing on off the main thread.  Firefox
4 has support for this.  It's unclear how much of a win this would be.

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

Re: [webkit-dev] A Parallel Webkit?

[Oliver Hunt]

On Jul 23, 2010, at 4:50 PM, Leo Meyerovich wrote:

> 
>> I wasn't entirely sure what OP was after of if the reply below
>> adequately addressed his interests.
> 
> WebKit2 seems to have little to do with taking advantage of parallel hardware 
> in browser algorithms like lexing, parsing, selectors, JS compilation, JS 
> execution, layout, DOM interactions, fonts, rendering, etc.

JS execution and DOM manipulation are single threaded, and that thread is the 
UI thread, this fact cannot be changed.  JS compilation is also done lazily in 
webkit so we don't ever end up with multiple pieces of code to compile 
concurrently.

--Oliver

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

Re: [webkit-dev] A Parallel Webkit?

[Leo Meyerovich]

> I wasn't entirely sure what OP was after of if the reply below
> adequately addressed his interests.

WebKit2 seems to have little to do with taking advantage of parallel hardware 
in browser algorithms like lexing, parsing, selectors, JS compilation, JS 
execution, layout, DOM interactions, fonts, rendering, etc. There is some 
benefit: Sam King measured bucketing coarse tasks at the process isolation 
level gives maybe 10-20% better utilization of cores (a la Google Chrome or 
predecessors like the OP browser, Charles Reis's work, Gazelle, ...) on a good 
workload.  WebKit2's goal of supporting concurrency might be aimed at 
foundations for building parallelism into library code, such as further 
cleaning up threading API or introducing lightweight task parallelism, but the 
description doesn't talk about such things.

In contrast, we're interested in magnitudes of speedup. Parallelism --- memory 
parallelism (hw + sw prefetching to avoid cache misses), SIMD instructions, 
multiple cores, etc -- and even sequential stuff (smaller data representation, 
balancing incrementalization/memoization, etc.). Parallelization is already 
standard for traditional media libraries within browsers (e.g., GPUs & SSE for 
painting and rendering); for maybe a third of our work, we're just expanding 
the scope of what algorithms should be tuned kernels in the HPC sense.

> 
> I guess I would just make a few comments about your considerations and our 
> experience.
> A somewhat different strategy than what you are proposing is to offload some 
> tasks
> to a more capable device such as a server- simply tokenizing html or compiling
> JS can be a big benefit in phone CPU and bandwidth (aka time and battery 
> life).

Opera mini is one stab at this, and the OnLive platform shows some of the 
potential here. However, this is for a limited deployment scenario and I'd 
actually argue against it from a power, energy, and latency perspective for 
handheld devices (... assuming you can get parallelization to work).


> You don't need to dig too deeply into the literature to find non monotonic 
> graphs
> of execution time for some task vs number of cores ( more can make things 
> slower).
> 


I agree -- it's tricky stuff. Worth keeping in mind handhelds will be in the 
multicore camp, not manycore, for awhile -- we're only now seeing dualcore 
ones: we don't need arbitrary strong scaling. Furthermore, frameworks like TBB 
are in a position to automate making the cutoff (which is actually non-obvious 
as you might want more threads than cores due to memory effects, 
hyperthreading, etc.). OTOH, for the processing style of browsers (sequences of 
little tasks), getting speedups isn't easy.


> I have seen this with transcoding and profiling on phone simulators- parsing
> and compiling is a great way to use time and create lots of objects ( and 
> these
> in java have lots of overhead and many phones only let you use java but in any
> case we know that temp objects are not free in any case and fragment memory). 


I'm actually surprised a project like WebKit doesn't use, as far as I've been 
able to tell, many memory pooling etc. optimizations. We've been mindful of 
this stuff in our work -- it's fairly standard in the performance community.


> Another rate limiting step has been the round trip delay to housekeep a 
> connection
> or do a DNS lookup. Here a proxy with persistent connections properly 
> implemented
> is a much bigger issue than optimized rendering or well transcoded web pages 
> AFAIK.
> 


Both the network and the CPU need work. For laptops, the network is typically 
the bottleneck, and only recently has that been shifting in the smart phone 
space. Worth noting, even on a fast network and local pages, profilers will 
show CPU bottlenecks.



> It may be worth considering making a standard compiled page type rather than
> worry about some of these other issues for example and cached compiled pages 
> of course
> greatly reduce problems for everyone. 


That's great and actually complementary -- parallel serialization of 
machine-generated formats is preferable to formats like HTML5. A lot of 
problems lie under the surface here, however: introducing a proxy somewhere 
introduces latency, not getting benefits on dynamic component loading, etc. I 
actually view making in-browser algorithms faster as the conservative choice.

> 
> Its important to remember that most of these things involve tradeoffs and
> there are many resources to consider.
> 
> So, maybe you can make various arguments (" but with wifi IO doesn't matter "
> or " CPU's are only getting faster" or "memory is only getting cheaper" ) and
> battle out platittudes to defend a given approach


We have never said any of these things. Mobile browsers take too much time 
processing and the hardware is going parallel in multiple ways; we're just 
putting 1+1 together. 


> but I wouldn't just point to 
> one, like parallelism, and assume that will fix everyt

[webkit-dev] Crash in RenderLayer related to setStyle() - Questions

[Alex Milowski]

I've identified a crash with the MathML implementation related to use of
CSS style rules that cause a RenderLayer instance to be created.  In the
MathML code's various createRenderer() methods, they always call
RenderObject::setStyle() on the object they've just created.

When the setStyle() method is called, a style difference is calculated
and propagated.  If you call setStyle() inside your createRenderer()
method, you're calling it on an unattached RenderObject instance.

Further, if there happens to be a rule like:

math {
   overflow: auto;
}

you'll get a layer created by RenderBoxModelObject.  That layer
will get the style change.

Right now, as the code stands, you'll get an exception and crash
due to the fact that the RenderLayer code makes some assumptions
about the RenderObject instance being attached to the tree.

The fix is trivial but my question is basically: what's the right thing
to do here?  Should the setStyle() be called in createRenderer() ?  It
seems like the answer is no because the style gets associated
somewhere else.  If I remove the call, the crash is also fixed (without
any change to RenderLayer) and the tests still all pass for MathML.

Further, should RenderLayer be made more safe?  Should it check
for zero pointer values in a couple places and avoid this?

If we shouldn't be calling setStyle() in createRenderer(), then fixing
RenderLayer would just hide that fact.  While an ASSERT wouldn't
hide things, it would still only arise when a layer is created.

I know how to fix the MathML code and I just want to make
sure I understand why calling setStyle() is "bad".

I'm not sure what should be done about RenderLayer or otherwise.

Suggestions?


-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] review queue crazy idea

[Dirk Pranke]

I have been thinking along these lines as well. I'm not sure how
relevant touching existing lines of code is versus just other people
who have hacked on the file at all or who have hacked on other files
in the same directory (i.e., you'd need to address new code and new
files, too). I think some empirical testing and tweaking would be the
way to evaluate this, though.

-- Dirk

On Fri, Jul 23, 2010 at 5:11 AM, Eric Seidel  wrote:
> Given a patch file, you have its line number ranges.
>
> Given a git checkout, you can very quickly find who has made changes
> to what lines in that file.
>
> You then can have a bot post to the bug, saying that 10 people have
> touched the lines you're touching in your patch.  3 of them are active
> reviewers, here are their names:
>
> You could even educate such a script/bot about "whitespace" or
> "rename" changes so they're excluded from any "who touched this"
> lookup.
>
> I would like to build (or see built) this (or a similar) script.  I
> just haven't had the time to do it.
>
> It's better than manual owner files or watch lists IMO because it's
> automatically generated.
>
> -eric
>
> On Fri, Jul 23, 2010 at 8:04 AM, Alex Milowski  wrote:
>> On Fri, Jul 23, 2010 at 12:51 PM, Eric Seidel  wrote:
>>> I've never really liked trac.webkit.org/wiki/WebKit%20Team.  Its
>>> always seemed more of place to brag about webkit involvement, than a
>>> useful reference.  I think we could build a much better "who should I
>>> ask to review this" tool based on SVN information.
>>
>> Were you thinking of some kind of automated "harvesting" of this information?
>>
>> I seems like a simple data file that can be processed by systems
>> would be a good way to start.  Then people can submit patches (or
>> commit changes) to file changing the areas that they are willing
>> to review and others can see/review that commitment.
>>
>> People who are looking for a reviewer can look through that file for
>> individuals.
>>
>> If a review doesn't want to get reminder e-mails or requests from
>> systems or individuals, they would then have to remove that
>> review "area" for themselves from that data file.
>>
>> I would personally use an XML format ... but that's me.  ;)
>>
>>
>> --
>> --Alex Milowski
>> "The excellence of grammar as a guide is proportional to the paucity of the
>> inflexions, i.e. to the degree of analysis effected by the language
>> considered."
>>
>> Bertrand Russell in a footnote of Principles of Mathematics
>> ___
>> 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

[webkit-dev] How to register another protocol handler

[Flávio Ceolin]

Hi folks,


I have a couple o doubts about how to register another protocol
handler on webkit.
First of all, is this a task for WebCore or the port ? I' ve searched
for it and I found something in ResourceHandle and PolicyCheck, which
one is responsible for that?
Second, is there a easy way to intercept a network request ? In the Qt
port it is easy to do this, simply reimplementing the
QNetworkAccessManager, but in the others ports ?
Do I have to create a new ResourceHandle class ?
Just to be clear, I want to do this, to load resources from
non-http/file storage.

Regards, Ceolin


Flavio Ceolin
ProFUSION Embedded Systems
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?

[Gustavo Sverzut Barbieri]

On Thu, Jul 22, 2010 at 11:07 PM, Darin Adler  wrote:
> On Jul 22, 2010, at 2:12 PM, Gustavo Sverzut Barbieri wrote:
>
>> Sorry to disturb this already dead thread, but we're (webkit-efl) thinking 
>> of letting applications/browsers register new protocol handlers to provide 
>> contents themselves. A co-worker, Flávio Ceolin, will send more details in 
>> another thread, but do you have any idea on the path to have them 
>> generically in WebCore?
>
> WebKit on Mac OS X already supports this and most other ports as well. Adding 
> it to a platform does not require any changes to WebCore.
>
> The frame policy functions in FrameLoaderClient are the hook for this sort of 
> thing, specifically dispatchDecidePolicyForNavigationAction. WebKit looks at 
> the URL and decides it’s something an application can handle based on the 
> OS-specific system for handling such things. Then if it does want to handle 
> it, it calls the frame policy function with the action "ignore", which 
> prevents WebCore from doing anything with the link, and then passes the URL 
> on to the other application.

Hi Darin,

Thanks! But not what I actually need... maybe I lacked an use case,
but my usage is not just to handle an URL, rather to provide actual
data to webkit based on them.

For instance, if I want to access an web archive in tar/zip/rar
without uncompressing, I'd like to be able, from my app, to load some
data with the base uri being "tar://" or maybe something that
identifies that file (tar://bla.tar.gz), and then all the relative
paths would be prepended "tar://", so I could trap it, access the file
inside the tar and then feed it back to webkit so the images are
shown, css are used, etc...

Maybe it is something else completely different? Ideas?

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] A Parallel Webkit?

[gao ying]

Thanks Andras! I will take a look at this.

-Ying

2010/7/23 Andras Becsi 

> Hi Ying,
>
> you might be looking for WebKit2, wich is a non-blocking API layer for
> WebKit and aims to make WebKit more suitable for multicore systems. It
> supports the split-process model and the thread model as well. The API is
> currently under development for the Mac and Windows ports of WebKit
> (Safari), and the Qt port also tries to keep pace with WebKit2 development,
> but currently lags behind the Mac and Win versions a bit. There is a test
> browser called MiniBrowser, you can try it if you are interested.
>
> You can find more information about WebKit2 at:
> http://trac.webkit.org/wiki/WebKit2
>
> regards,
> Andras
>
>
> 2010-07-22 17:43 keltezéssel, gao ying írta:
>
>> Hi,
>>
>> Is WebKit well parallel for fitting in multicore architecture? And any
>> status for the parallel Webkit? The same idea is from
>> http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/
>>
>> Thanks,
>> -Ying
>>
>>
>>
>> ___
>> 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] A Parallel Webkit?

[gao ying]

Hi Marchywka ,

Thanks for your comments about the paralle browser.:)

Your point is that exeucution can not benifit from multi-thread multi-core
for the following reasons:
1) Inter-thread compete
2) Cache thrashing (false sharing)
3) task offload overhead (BW limitation etc)

Generally, all these bullets are true for multi-thread workload whether or
not it is browser. Do you have any data for showing these worse in mobile
device?

1) Inter-thread compete
There are some solutions which can reduce the compete. For example, you can
select a suitable execution model (producer-consumer, Bulk synchronous
parallel) for a specific workload.
2) Cache thrashing (false sharing)
App has to take care of the memory locality and reduce the working set.
3) task offload overhead (BW limitation etc)
The task partitioner should offload the coarse task to device or accelator
for less communication overhead.

Thanks,
-Ying

2010/7/23 Mike Marchywka 

>
>
>
> I wasn't entirely sure what OP was after of if the reply below
> adequately addressed his interests. After looking at the link
> provided, I thought I would make a few comments that may or
> may not be of much benefit ( for discussion ) but that relate
> to observations on a few recent browsers on one series of mobile phones.
>
>
>
>
> 
> > Date: Thu, 22 Jul 2010 22:20:34 +0200
> > From: abe...@inf.u-szeged.hu
> > To: webkit-dev@lists.webkit.org
> > Subject: Re: [webkit-dev] A Parallel Webkit?
> >
> > Hi Ying,
> >
> > you might be looking for WebKit2, wich is a non-blocking API layer for
> > WebKit and aims to make WebKit more suitable for multicore systems. It
> > supports the split-process model and the thread model as well. The API
> > is currently under development for the Mac and Windows ports of WebKit
> > (Safari), and the Qt port also tries to keep pace with WebKit2
> > development, but currently lags behind the Mac and Win versions a bit.
> > There is a test browser called MiniBrowser, you can try it if you are
> > interested.
> >
> > You can find more information about WebKit2 at:
> > http://trac.webkit.org/wiki/WebKit2
> >
> > regards,
> > Andras
> >
> >
> > 2010-07-22 17:43 keltezéssel, gao ying írta:
> >> Hi,
> >>
> >> Is WebKit well parallel for fitting in multicore architecture? And any
> >> status for the parallel Webkit? The same idea is from
> >> http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/
>
>
> I guess I would just make a few comments about your considerations and our
> experience.
> A somewhat different strategy than what you are proposing is to offload
> some tasks
> to a more capable device such as a server- simply tokenizing html or
> compiling
> JS can be a big benefit in phone CPU and bandwidth (aka time and battery
> life).
> Many people rush to parallelism even with only one core or may try to
> use many cores and then they compete with each other, often thrashing
> memory
> caches or worse going to VM ( on smaller desktop computers like mine this
> is a problem).
> You don't need to dig too deeply into the literature to find non monotonic
> graphs
> of execution time for some task vs number of cores ( more can make things
> slower).
>
> I have seen this with transcoding and profiling on phone simulators-
> parsing
> and compiling is a great way to use time and create lots of objects ( and
> these
> in java have lots of overhead and many phones only let you use java but in
> any
> case we know that temp objects are not free in any case and fragment
> memory).
> Another rate limiting step has been the round trip delay to housekeep a
> connection
> or do a DNS lookup. Here a proxy with persistent connections properly
> implemented
> is a much bigger issue than optimized rendering or well transcoded web
> pages AFAIK.
>
> It may be worth considering making a standard compiled page type rather
> than
> worry about some of these other issues for example and cached compiled
> pages of course
> greatly reduce problems for everyone.
>
> Its important to remember that most of these things involve tradeoffs and
> there are many resources to consider.
>
> So, maybe you can make various arguments (" but with wifi IO doesn't matter
> "
> or " CPU's are only getting faster" or "memory is only getting cheaper" )
> and
> battle out platittudes to defend a given approach but I wouldn't just point
> to
> one, like parallelism, and assume that will fix everything and indeed it
> can make things
> worse. Making things smaller in a way you don't need to undo ( say use
> winzip to download
> and then unzip the html only to compile it etc) is potentially a benefit in
> any situation
> as long as radio usage requires power.
>
> An immediate concern I would point to in regard to multithreading on
> desktop
> and mobile is the need to keep a responsive UI thread- not sure if webkit
> has
> addressed this fully but I have seen this as a huge problem on my des

Re: [webkit-dev] review queue crazy idea

[Alex Milowski]

On Fri, Jul 23, 2010 at 1:15 PM, Alex Milowski  wrote:
> On Fri, Jul 23, 2010 at 1:11 PM, Eric Seidel  wrote:
>> Given a patch file, you have its line number ranges.
>>
>> Given a git checkout, you can very quickly find who has made changes
>> to what lines in that file.
>>
>> You then can have a bot post to the bug, saying that 10 people have
>> touched the lines you're touching in your patch.  3 of them are active
>> reviewers, here are their names:
>
> That sounds like a "heat map" for code.  I wonder if there are existing
> tools that do that?

This looks interesting:

   http://www.statsvn.org/

I'm not sure if it can answer "this line of code has these reviewers" but
it is worth a look.

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] review queue crazy idea

[Alex Milowski]

On Fri, Jul 23, 2010 at 1:11 PM, Eric Seidel  wrote:
> Given a patch file, you have its line number ranges.
>
> Given a git checkout, you can very quickly find who has made changes
> to what lines in that file.
>
> You then can have a bot post to the bug, saying that 10 people have
> touched the lines you're touching in your patch.  3 of them are active
> reviewers, here are their names:

That sounds like a "heat map" for code.  I wonder if there are existing
tools that do that?

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] review queue crazy idea

[Eric Seidel]

Given a patch file, you have its line number ranges.

Given a git checkout, you can very quickly find who has made changes
to what lines in that file.

You then can have a bot post to the bug, saying that 10 people have
touched the lines you're touching in your patch.  3 of them are active
reviewers, here are their names:

You could even educate such a script/bot about "whitespace" or
"rename" changes so they're excluded from any "who touched this"
lookup.

I would like to build (or see built) this (or a similar) script.  I
just haven't had the time to do it.

It's better than manual owner files or watch lists IMO because it's
automatically generated.

-eric

On Fri, Jul 23, 2010 at 8:04 AM, Alex Milowski  wrote:
> On Fri, Jul 23, 2010 at 12:51 PM, Eric Seidel  wrote:
>> I've never really liked trac.webkit.org/wiki/WebKit%20Team.  Its
>> always seemed more of place to brag about webkit involvement, than a
>> useful reference.  I think we could build a much better "who should I
>> ask to review this" tool based on SVN information.
>
> Were you thinking of some kind of automated "harvesting" of this information?
>
> I seems like a simple data file that can be processed by systems
> would be a good way to start.  Then people can submit patches (or
> commit changes) to file changing the areas that they are willing
> to review and others can see/review that commitment.
>
> People who are looking for a reviewer can look through that file for
> individuals.
>
> If a review doesn't want to get reminder e-mails or requests from
> systems or individuals, they would then have to remove that
> review "area" for themselves from that data file.
>
> I would personally use an XML format ... but that's me.  ;)
>
>
> --
> --Alex Milowski
> "The excellence of grammar as a guide is proportional to the paucity of the
> inflexions, i.e. to the degree of analysis effected by the language
> considered."
>
> Bertrand Russell in a footnote of Principles of Mathematics
> ___
> 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 crazy idea

[Alex Milowski]

On Fri, Jul 23, 2010 at 12:51 PM, Eric Seidel  wrote:
> I've never really liked trac.webkit.org/wiki/WebKit%20Team.  Its
> always seemed more of place to brag about webkit involvement, than a
> useful reference.  I think we could build a much better "who should I
> ask to review this" tool based on SVN information.

Were you thinking of some kind of automated "harvesting" of this information?

I seems like a simple data file that can be processed by systems
would be a good way to start.  Then people can submit patches (or
commit changes) to file changing the areas that they are willing
to review and others can see/review that commitment.

People who are looking for a reviewer can look through that file for
individuals.

If a review doesn't want to get reminder e-mails or requests from
systems or individuals, they would then have to remove that
review "area" for themselves from that data file.

I would personally use an XML format ... but that's me.  ;)


-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] review queue crazy idea

[Eric Seidel]

I've never really liked trac.webkit.org/wiki/WebKit%20Team.  Its
always seemed more of place to brag about webkit involvement, than a
useful reference.  I think we could build a much better "who should I
ask to review this" tool based on SVN information.

-eric

On Fri, Jul 23, 2010 at 12:15 AM, David Kilzer  wrote:
> We should also publicize/update these existing resources to help patch 
> authors find reviewers for their patches:
>
> http://trac.webkit.org/wiki/CodeReview
> http://trac.webkit.org/wiki/WebKit%20Team
>
> I think the most effective approach is when patch authors proactively seek 
> out reviewers.  We're all busy, but when I'm asked to review a patch, I make 
> time for it or point the person at another reviewer.
>
> Dave
> --
> Sent from my iPhone 4
>
> On Jul 22, 2010, at 12:29 AM, Maciej Stachowiak  wrote:
>
>>
>> On Jul 21, 2010, at 3:41 PM, Eric Seidel wrote:
>>
>>> Wow.  I really like this idea of helping contributors better
>>> understand what's going wrong.
>>>
>>> But, I think that even better would be to build a better front-end for
>>> reviews.  Or a bot which knew how to suggest reviewers (based on
>>> annotate information from lines changed).
>>
>>
>> I think a better UI for reviews, plus some better attempts at active 
>> notification of potential reviewers, could go a long way. I'm a strong 
>> believer in trying nudges and positive incentives before implementing 
>> harsher policies.
>>
>> Regards,
>> Maciej
>>
>> ___
>> 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