Re: [webkit-dev] help with failing test on SnowLeopard Intel Release (WebKit2 Tests)
On Wed, Mar 23, 2011 at 1:45 AM, Ojan Vafai o...@chromium.org wrote: For example, the following fails on my SnowLeopard machine due to lacking the focus ring: run-webkit-tests --debug -2 fast/css/focus-ring-outline-color.html -p --tolerance 0 This sounds very familiar to me. On Snow Leopard (not on Leopard) there exists a bug where the system fails to draw a focus ring when drawing a control into a context. See ThemeChromiumMac.mm's currentOSHasSetFocusRingStyleInBitmapBug() for more details. I solved it by doing an ugly interposing hack. It wasn't needed for WebKit because its controls draw directly into the window. Perhaps it's needed for WebKit2? Email me if you need more info. (For Apple peeps: rdar://7604051) Avi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system update
On 2011-03-23, at 03:33, Adam Barth wrote: On Wed, Mar 23, 2011 at 12:22 AM, Mark Rowe mr...@apple.com wrote: On 2011-03-22, at 23:50, Adam Barth wrote: On Tue, Mar 22, 2011 at 8:14 PM, Mark Rowe mr...@apple.com wrote: Product names for targets are redundantly declared in the Xcode project when they're already defined in the .xcconfig files. My plan for this issue is to remove the product names from the xcconfig files once they're not needed by the generated xcodeproj files. That seems backwards. JavaScriptCore.xcconfig defines how to create JavaScriptCore.framework. The name of the framework (e.g., PRODUCT_NAME) is an important part of that, much like the install path, Info.plist file, etc. I don't see how we benefit from that information being spread around. The information about how to create JavaScriptCore.framework is already spread around to a certain extent. For example, JavaScriptCore.xcconfig does not contain the list of files that need to be built or information about the dependencies. I'm having a hard time seeing what the practical difference is between specifying the product name in the xcodeproj file or the xcconfig file. What's the argument for changing where it is specified? Is it simply because gyp doesn't know better? One area that I could use some help from one or more Apple folks is making sure that this build system integrates properly with Apple's internal build system. Based on my (incomplete!) understanding of Apple's internal build system, there are at least two options: 1) Apple's internal build system consumes Source in its entirety and builds a master WebKit.xcodeproj (or a Makefile), which abstracts further details about the build, such as how subsequent xcodeproj are created or how many libraries WebKit is factored into (e.g., letting us extract WTF from JavaScriptCore). Making that particular change is completely unrelated to GYP. My understanding is that it would solve the Apple internal build system integration issue because the Apple internal build system would transfer control to the master WebKit.xcodeproj, which could then invoke GYP to generate the remaining xcodeproj files. I'm not particularly keen on a solution that involves manually invoking xcodebuild to build projects. It becomes very complicated to ensure that the correct settings, including any overridden settings, make it down to the nested invocations of xcodebuild. I'm not sure I've correctly communicated how I envision this approach working. If approach (2) doesn't work out for whatever reason, I can build a mockup of how this would work, which will be more concrete. You'll need to provide more detail then because I cannot see how this would work in a manner that doesn't cause the problems I have noted. 2) For each submission to Apple's internal build system, we create a branch, generate xcodeproj files, and check them into the branch. Apple's internal build system can then svn export the branch and see xcodeproj files, as today. While this is certainly technically feasible, it would add a huge amount of overhead to the process of performing a submission. How often do you submit WebKit to the Apple internal build system? If that's sensitive information, I'm just looking for an order of magnitude (e.g., every revision, every hour, every day, every week). As a reference, the Chromium project creates one branch per day for daily builds. I don't see how the frequency is relevant. The relevancy arises from the observation that the overhead is proportional to the frequency. If we only submit WebKit to Apple's internal build system once a week, then this approach won't cause too much branch proliferation. If, on the other hand, we're submitting every revision, then we're talking about doubling or tripling the revision burn rate, which might not be desirable. The rate at which we use SVN revisions or the number of branches isn't of particular concern to me. The simple fact is that your proposal turns a single, trivial operation (create a tag) in to a sequence of more complicated operations (create a branch, check it out, run a script to generate a bunch of files, test that it builds, commit the new files, create a tag). What used to be a single command-line operation that took a second to run is now a series of operations that takes 5+ minutes to complete. In any case, I'm glad we've found a technically feasible solution. We've had at least one technically feasible solution from day zip: check in the generated project files. From my perspective, approach (2) is more desirable than checking in generated project files because approach (2) encapsulates Apple-internal build process to Apple folks, more specifically to the Apple folks who interact with the Apple-internal build system. Checking in generated project files, on the other hand, imposes a maintenance burden on all WebKit
Re: [webkit-dev] Build system update
On Wed, Mar 23, 2011 at 3:33 AM, Adam Barth aba...@webkit.org wrote: On Wed, Mar 23, 2011 at 12:22 AM, Mark Rowe mr...@apple.com wrote: In any case, I'm glad we've found a technically feasible solution. We've had at least one technically feasible solution from day zip: check in the generated project files. From my perspective, approach (2) is more desirable than checking in generated project files because approach (2) encapsulates Apple-internal build process to Apple folks, more specifically to the Apple folks who interact with the Apple-internal build system. Checking in generated project files, on the other hand, imposes a maintenance burden on all WebKit contributors. Living with the chromium system of generating the files on the fly, I always find it bothersome when the slowest step (by far) of my sync is generating these project files. So I personally prefer checking in the generated files (and letting this delay be on the person making the change -- rather than distributing this generation step to everyone). (As Mark mentions) this seems to also have the benefit of disrupting people's workflow the least. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system update
On Wed, Mar 23, 2011 at 1:33 PM, David Levin le...@google.com wrote: On Wed, Mar 23, 2011 at 12:17 PM, Adam Barth aba...@webkit.org wrote: $ time git svn rebase [... update my working copy from changes during lunch (four revisions) ...] real 1m10.316s user 0m8.194s sys 0m16.400s $ time ./Tools/Scripts/generate-project-files real 0m4.339s user 0m3.888s sys 0m0.269s which is about 6.1% overhead on an almost trivial update. We can also reduce this overhead to zero in many cases by detecting that we don't need to re-generate the project files if the inputs to the generation process haven't changed. It looks like you are using a slow mechanism for syncing. :) TLDR version: 8% overhead for updating 191 revisions. 49% overhead for trivial sync (3 revisions) -- in addition to the added complexity (when I sync or switch branches in git). Here's my results for updating 191 revisions (81605 through 81796). $ time git fetch time git svn rebase fetch, svn rebase times real 0m21.071s, 0m36.195s user 0m2.271s, 0m3.205s sys 0m0.497s, 0m9.428s total 57 seconds for a nontrivial update. $ time ./Tools/Scripts/generate-project-files real 0m4.642s user 0m4.243s sys 0m0.322s An 8% overhead on a non-trivial sync. For a trivial update of 3 revisions: real 0m3.490s, 0m6.017s user 0m0.932s, 0m2.266s sys 0m0.184s, 0m2.824s For a total of 9.5 seconds. The generate project files step remained the same, so this adds a 49% overhead for a trivial sync. It also adds time (and complications) whenever I switch branches in git. dave PS For chromium, my experience is $ time gclient runhooks --force real 0m42.459s user 0m29.236s sys 0m2.543s I don't know enough about chromium build system and gyp to know why it is an order of magnitude slower, but this overhead is noticeable and annoying there. I love the idea of a one project file system, but I have concerns about project file generation on sync becoming the norm in WebKit. fwiw, I checked how many gyp files were in chromium and it appeared within 20%. There seem to be four approaches to improving this situation: 1) Check in the generated project files. In this approach, only one person pays the cost of generating the project files. 2) Make generate-project-files run faster. I haven't looked at what's taking 4 seconds, but it seems entirely possible that we can improve the performance. 3) Avoid running generate-project-files when not necessary. This approach would improve the performance of the trivial sync, for example. 4) Run generate-project-files at time other than sync. For example, we could run generate-project-files as part of build-webkit, which already takes more more than 4 seconds, leading to a lower percentage overhead. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system update
On 2011-03-23, at 13:49, Adam Barth wrote: On Wed, Mar 23, 2011 at 1:33 PM, David Levin le...@google.com wrote: On Wed, Mar 23, 2011 at 12:17 PM, Adam Barth aba...@webkit.org wrote: $ time git svn rebase [... update my working copy from changes during lunch (four revisions) ...] real1m10.316s user0m8.194s sys 0m16.400s $ time ./Tools/Scripts/generate-project-files real0m4.339s user0m3.888s sys 0m0.269s which is about 6.1% overhead on an almost trivial update. We can also reduce this overhead to zero in many cases by detecting that we don't need to re-generate the project files if the inputs to the generation process haven't changed. It looks like you are using a slow mechanism for syncing. :) TLDR version: 8% overhead for updating 191 revisions. 49% overhead for trivial sync (3 revisions) -- in addition to the added complexity (when I sync or switch branches in git). Here's my results for updating 191 revisions (81605 through 81796). $ time git fetch time git svn rebase fetch, svn rebase times real 0m21.071s, 0m36.195s user 0m2.271s, 0m3.205s sys 0m0.497s, 0m9.428s total 57 seconds for a nontrivial update. $ time ./Tools/Scripts/generate-project-files real 0m4.642s user 0m4.243s sys 0m0.322s An 8% overhead on a non-trivial sync. For a trivial update of 3 revisions: real 0m3.490s, 0m6.017s user 0m0.932s, 0m2.266s sys 0m0.184s, 0m2.824s For a total of 9.5 seconds. The generate project files step remained the same, so this adds a 49% overhead for a trivial sync. It also adds time (and complications) whenever I switch branches in git. dave PS For chromium, my experience is $ time gclient runhooks --force real 0m42.459s user 0m29.236s sys 0m2.543s I don't know enough about chromium build system and gyp to know why it is an order of magnitude slower, but this overhead is noticeable and annoying there. I love the idea of a one project file system, but I have concerns about project file generation on sync becoming the norm in WebKit. fwiw, I checked how many gyp files were in chromium and it appeared within 20%. There seem to be four approaches to improving this situation: 1) Check in the generated project files. In this approach, only one person pays the cost of generating the project files. 2) Make generate-project-files run faster. I haven't looked at what's taking 4 seconds, but it seems entirely possible that we can improve the performance. 3) Avoid running generate-project-files when not necessary. This approach would improve the performance of the trivial sync, for example. 4) Run generate-project-files at time other than sync. For example, we could run generate-project-files as part of build-webkit, which already takes more more than 4 seconds, leading to a lower percentage overhead. People build much more frequently than the update, so 4 would have to be done in conjunction with 2 and/or 3. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system update
On Wed, Mar 23, 2011 at 1:58 PM, Mark Rowe mr...@apple.com wrote: On 2011-03-23, at 13:49, Adam Barth wrote: On Wed, Mar 23, 2011 at 1:33 PM, David Levin le...@google.com wrote: On Wed, Mar 23, 2011 at 12:17 PM, Adam Barth aba...@webkit.org wrote: $ time git svn rebase [... update my working copy from changes during lunch (four revisions) ...] real 1m10.316s user 0m8.194s sys 0m16.400s $ time ./Tools/Scripts/generate-project-files real 0m4.339s user 0m3.888s sys 0m0.269s which is about 6.1% overhead on an almost trivial update. We can also reduce this overhead to zero in many cases by detecting that we don't need to re-generate the project files if the inputs to the generation process haven't changed. It looks like you are using a slow mechanism for syncing. :) TLDR version: 8% overhead for updating 191 revisions. 49% overhead for trivial sync (3 revisions) -- in addition to the added complexity (when I sync or switch branches in git). Here's my results for updating 191 revisions (81605 through 81796). $ time git fetch time git svn rebase fetch, svn rebase times real 0m21.071s, 0m36.195s user 0m2.271s, 0m3.205s sys 0m0.497s, 0m9.428s total 57 seconds for a nontrivial update. $ time ./Tools/Scripts/generate-project-files real 0m4.642s user 0m4.243s sys 0m0.322s An 8% overhead on a non-trivial sync. For a trivial update of 3 revisions: real 0m3.490s, 0m6.017s user 0m0.932s, 0m2.266s sys 0m0.184s, 0m2.824s For a total of 9.5 seconds. The generate project files step remained the same, so this adds a 49% overhead for a trivial sync. It also adds time (and complications) whenever I switch branches in git. dave PS For chromium, my experience is $ time gclient runhooks --force real 0m42.459s user 0m29.236s sys 0m2.543s I don't know enough about chromium build system and gyp to know why it is an order of magnitude slower, but this overhead is noticeable and annoying there. I love the idea of a one project file system, but I have concerns about project file generation on sync becoming the norm in WebKit. fwiw, I checked how many gyp files were in chromium and it appeared within 20%. There seem to be four approaches to improving this situation: 1) Check in the generated project files. In this approach, only one person pays the cost of generating the project files. 2) Make generate-project-files run faster. I haven't looked at what's taking 4 seconds, but it seems entirely possible that we can improve the performance. 3) Avoid running generate-project-files when not necessary. This approach would improve the performance of the trivial sync, for example. 4) Run generate-project-files at time other than sync. For example, we could run generate-project-files as part of build-webkit, which already takes more more than 4 seconds, leading to a lower percentage overhead. People build much more frequently than the update, so 4 would have to be done in conjunction with 2 and/or 3. Indeed. I suspect (2) and (3) are worth doing regardless. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system update
On Wed, Mar 23, 2011 at 2:08 PM, Adam Barth aba...@webkit.org wrote: Indeed. I suspect (2) and (3) are worth doing regardless. AFAIK, gyp currently always regenerates everything and then compares the new versions to the old to see if it actually needs to touch the files on disk. This seems safe but slow. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system update
On Wed, Mar 23, 2011 at 2:13 PM, Peter Kasting pkast...@chromium.org wrote: On Wed, Mar 23, 2011 at 2:08 PM, Adam Barth aba...@webkit.org wrote: Indeed. I suspect (2) and (3) are worth doing regardless. AFAIK, gyp currently always regenerates everything and then compares the new versions to the old to see if it actually needs to touch the files on disk. This seems safe but slow. My plan is to use a make-like system to stat the input files and compare the last-modified date with the output files. That approach seems to work well for other aspects of the build system. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system update
On Wed, Mar 23, 2011 at 1:33 PM, David Levin le...@google.com wrote: On Wed, Mar 23, 2011 at 12:17 PM, Adam Barth aba...@webkit.org wrote: $ time git svn rebase [... update my working copy from changes during lunch (four revisions) ...] real 1m10.316s user 0m8.194s sys 0m16.400s $ time ./Tools/Scripts/generate-project-files real 0m4.339s user 0m3.888s sys 0m0.269s which is about 6.1% overhead on an almost trivial update. We can also reduce this overhead to zero in many cases by detecting that we don't need to re-generate the project files if the inputs to the generation process haven't changed. It looks like you are using a slow mechanism for syncing. :) TLDR version: 8% overhead for updating 191 revisions. 49% overhead for trivial sync (3 revisions) -- in addition to the added complexity (when I sync or switch branches in git). Here's my results for updating 191 revisions (81605 through 81796). $ time git fetch time git svn rebase fetch, svn rebase times real 0m21.071s, 0m36.195s user 0m2.271s, 0m3.205s sys 0m0.497s, 0m9.428s total 57 seconds for a nontrivial update. $ time ./Tools/Scripts/generate-project-files real 0m4.642s user 0m4.243s sys 0m0.322s An 8% overhead on a non-trivial sync. For a trivial update of 3 revisions: real 0m3.490s, 0m6.017s user 0m0.932s, 0m2.266s sys 0m0.184s, 0m2.824s For a total of 9.5 seconds. The generate project files step remained the same, so this adds a 49% overhead for a trivial sync. It also adds time (and complications) whenever I switch branches in git. dave PS For chromium, my experience is $ time gclient runhooks --force real 0m42.459s user 0m29.236s sys 0m2.543s I don't know enough about chromium build system and gyp to know why it is an order of magnitude slower, but this overhead is noticeable and annoying there. I love the idea of a one project file system, but I have concerns about project file generation on sync becoming the norm in WebKit. fwiw, I checked how many gyp files were in chromium and it appeared within 20%. FWIW, with Chromium, the regular 'gclient sync' regenerates the project files even if it didn't update anything, which is a step that could probably be eliminated. Also, as far as I know, there's been little effort to profile and optimize gyp, so I bet we could probably speed things up a fair amount. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] help with failing test on SnowLeopard Intel Release (WebKit2 Tests)
On Wed, Mar 23, 2011 at 11:38 PM, Avi Drissman a...@google.com wrote: On Wed, Mar 23, 2011 at 1:45 AM, Ojan Vafai o...@chromium.org wrote: For example, the following fails on my SnowLeopard machine due to lacking the focus ring: run-webkit-tests --debug -2 fast/css/focus-ring-outline-color.html -p --tolerance 0 This sounds very familiar to me. On Snow Leopard (not on Leopard) there exists a bug where the system fails to draw a focus ring when drawing a control into a context. See ThemeChromiumMac.mm's currentOSHasSetFocusRingStyleInBitmapBug() for more details. I solved it by doing an ugly interposing hack. It wasn't needed for WebKit because its controls draw directly into the window. Perhaps it's needed for WebKit2? Email me if you need more info. (For Apple peeps: rdar://7604051) This isn't a painting bug. It's failing to return a value for document.querySelector(a:focus). In fact, I wonder if this is really correct behavior. Perhaps querySelector of :focus should return the document's focused element even if the window is blurred (analogous to document.activeElement)? Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] help with failing test on SnowLeopard Intel Release (WebKit2 Tests)
Will do. On Thu, Mar 24, 2011 at 2:44 AM, Adam Roben aro...@apple.com wrote: On Mar 23, 2011, at 1:47 AM, Ojan Vafai wrote: People who work on WebKit2: should I check in the failing result and/or does someone want to look into the focus issue? Checking in failing results and filing a bug would be great. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system update
On Mar 23, 2011, at 3:33 AM, Adam Barth wrote: While this is certainly technically feasible, it would add a huge amount of overhead to the process of performing a submission. How often do you submit WebKit to the Apple internal build system? If that's sensitive information, I'm just looking for an order of magnitude (e.g., every revision, every hour, every day, every week). As a reference, the Chromium project creates one branch per day for daily builds. I don't see how the frequency is relevant. The relevancy arises from the observation that the overhead is proportional to the frequency. If we only submit WebKit to Apple's internal build system once a week, then this approach won't cause too much branch proliferation. If, on the other hand, we're submitting every revision, then we're talking about doubling or tripling the revision burn rate, which might not be desirable. In any case, I'm glad we've found a technically feasible solution. We've had at least one technically feasible solution from day zip: check in the generated project files. From my perspective, approach (2) is more desirable than checking in generated project files because approach (2) encapsulates Apple-internal build process to Apple folks, more specifically to the Apple folks who interact with the Apple-internal build system. Checking in generated project files, on the other hand, imposes a maintenance burden on all WebKit contributors. I believe Apple submissions generally happen with greater frequency than the rate at which new files are added to the project. Furthermore: When files are added to the project, the patch submitted must already run the tool to regenerate projects, and is already going to submit a patch, so the maintenance burden of the Xcode projects being checked in is low. But having to regenerate project files and then check them in on a branch adds extra steps, doing things that are not done in the normal course of development, and therefore may have bitrotted. I don't think you are going to get Apple folks enthusiastic about switching to a build system that creates significantly more work for us, on the basis that it saves everyone else a small amount of work. For that matter, slowing down the pace of Apple engineers' development would be a bad thing for the project overall, not just for Apple. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] help with failing test on SnowLeopard Intel Release (WebKit2 Tests)
It could just be a bug with WebKitTestRunner; it may be failing to focus the window. - Maciej On Mar 22, 2011, at 10:45 PM, Ojan Vafai wrote: Actually, looks like this is a WebKit2-related bug. It just happens that this is the only non-pixel test that depends on the window having focus. For example, the following fails on my SnowLeopard machine due to lacking the focus ring: run-webkit-tests --debug -2 fast/css/focus-ring-outline-color.html -p --tolerance 0 On Wed, Mar 23, 2011 at 4:13 PM, Stephanie Lewis sle...@apple.com wrote: The machine did have a software update dialog up. However, i dismissed the dialog and the test is still failing. -- Stephanie On Mar 22, 2011, at 9:29 PM, Ojan Vafai wrote: fast/css/pseudo-any.html is failing on SnowLeopard Intel Release (WebKit2 Tests), but it's not failing on SnowLeopard Intel Release (Tests). The test depends on the window having focus and the failure it's getting is the one you get if you load the page in a blurred window. So, I assume some dialog or something is up on that bot causing focus issues. What I don't get is that there are other tests that depend on the window having focus that don't seem to be failing on this bot. Does someone with access to the bot mind taking a look? Ojan ___ 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] help with failing test on SnowLeopard Intel Release (WebKit2 Tests)
Filed https://bugs.webkit.org/show_bug.cgi?id=56988. On Thu, Mar 24, 2011 at 2:53 PM, Maciej Stachowiak m...@apple.com wrote: It could just be a bug with WebKitTestRunner; it may be failing to focus the window. - Maciej On Mar 22, 2011, at 10:45 PM, Ojan Vafai wrote: Actually, looks like this is a WebKit2-related bug. It just happens that this is the only non-pixel test that depends on the window having focus. For example, the following fails on my SnowLeopard machine due to lacking the focus ring: run-webkit-tests --debug -2 fast/css/focus-ring-outline-color.html -p --tolerance 0 On Wed, Mar 23, 2011 at 4:13 PM, Stephanie Lewis sle...@apple.com wrote: The machine did have a software update dialog up. However, i dismissed the dialog and the test is still failing. -- Stephanie On Mar 22, 2011, at 9:29 PM, Ojan Vafai wrote: fast/css/pseudo-any.html is failing on SnowLeopard Intel Release (WebKit2 Tests), but it's not failing on SnowLeopard Intel Release (Tests). The test depends on the window having focus and the failure it's getting is the one you get if you load the page in a blurred window. So, I assume some dialog or something is up on that bot causing focus issues. What I don't get is that there are other tests that depend on the window having focus that don't seem to be failing on this bot. Does someone with access to the bot mind taking a look? Ojan ___ 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
