Re: [webkit-dev] Constant readonly
Hi Darin,
I understand.
thanks for your help.
Mario
On lundi 22 novembre 2010 17:23:18 Darin Adler wrote:
On Nov 22, 2010, at 2:41 AM, Mario Bensi wrote:
I tested if the constant in idl was readonly, like that :
var node = document.getElementById('console');
alert(node.ELEMENT_NODE);
node.ELEMENT_NODE = 666;
alert(node.ELEMENT_NODE);
And it's strange, I can change ELEMENT_NODE value.
I know it's stupid to do this but is it the correct behaviour ?
The property ELEMENT_NODE is read-only on the prototype for nodes. But
there’s no rule against creating a property of the same name on an individual
node. That is what your code does.
If you try:
Node.ELEMENT_NODE = 666;
You’ll see that you can’t change the value on the prototype for nodes.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Waiting time for patch with commit? status.
Hello, If I flag a patch with commit?, do I need to notify some commiters? Or are those commit? patches get periodically processed by someone, I just need to wait. If the latter is the case, what's the average waiting time. Thanks. Jia___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Waiting time for patch with commit? status.
Sometimes some individuals take it upon themselves to process all the commit-queue? patches, but I don't think we have a formal process like we do with reviews. Pinging on the bug and/or on the #webkit IRC channel are both acceptable. On Tue, Nov 30, 2010 at 8:40 AM, Jia Pu j...@apple.com wrote: Hello, If I flag a patch with commit?, do I need to notify some commiters? Or are those commit? patches get periodically processed by someone, I just need to wait. If the latter is the case, what's the average waiting time. Thanks. Jia ___ 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] Waiting time for patch with commit? status.
Marking commit-queue? is just like marking review?. Mails get sent, but you often have to bug people to get your review+ or commit-queue+. -eric On Tue, Nov 30, 2010 at 8:40 AM, Jia Pu j...@apple.com wrote: Hello, If I flag a patch with commit?, do I need to notify some commiters? Or are those commit? patches get periodically processed by someone, I just need to wait. If the latter is the case, what's the average waiting time. Thanks. Jia ___ 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] Waiting time for patch with commit? status.
I don't know if my behavior is typical but I almost never scan the commit queue. I occasionally scan the review queue. So changing an already r+'ed bug to have cq? may not get noticed. I'd ping someone to be sure (and there are more committers than reviewers so you have more options even). dave On Tue, Nov 30, 2010 at 10:58 AM, Eric Seidel e...@webkit.org wrote: Marking commit-queue? is just like marking review?. Mails get sent, but you often have to bug people to get your review+ or commit-queue+. -eric On Tue, Nov 30, 2010 at 8:40 AM, Jia Pu j...@apple.com wrote: Hello, If I flag a patch with commit?, do I need to notify some commiters? Or are those commit? patches get periodically processed by someone, I just need to wait. If the latter is the case, what's the average waiting time. Thanks. Jia ___ 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] Faster Git SVN updates
I've now posted a patch to fix update-webkit as well: https://bugs.webkit.org/show_bug.cgi?id=50273 Once that lands, I'll move the EWS bots over to using this new setup. Assuming those stay working, we can teach the tools to offer to fix old setups. -eric On Mon, Nov 22, 2010 at 4:58 PM, Ojan Vafai o...@chromium.org wrote: http://trac.webkit.org/changeset/72575 for having scm.py do the right thing. On Thu, Nov 18, 2010 at 4:11 PM, Eric Seidel e...@webkit.org wrote: OK. Sounds we should make this setup default. I'll see if we can't educate update-webkit and webkitpy/common/checkout/scm.py about detecting this setup and doing the right thing in that case. I'll file a separate bug about making scm.py's Git object use --no-rebase during dcommit. -eric On Thu, Nov 18, 2010 at 4:08 PM, Evan Martin e...@chromium.org wrote: On Thu, Nov 18, 2010 at 3:36 PM, David Levin le...@google.com wrote: It's some magical setup by which your git svn fetchs will be much faser. But I've heard it's buggy? Can lead to local repository corruption? Can someone set me straight? No magic, just standard git: complicated, but logical once you understand how it works. :\ It means that both git pull and git svn fetch will be updating the same branch. When the latter sees the former has pulled down new stuff (quickly, via the fast git protocol), it knows to rebuild its metadata from the new stuff you fetched (rather than fetching it all over again via the slow svn protocol). There's a catch: if you git svn fetch, that creates new commits locally. When you later git pull, you get the commits that were constructed by git.webkit.org, which don't match (due to differing timestamps). This may screw up rebase, but I believe it's smart enough to recognize the commits are the same (applied the same diff; in git jargon, they have the same patch-id). In practice you don't even run git svn fetch except when the git server is behind, so I don't know if there are corner cases here that I haven't run into. (I also haven't tried this on Windows in a while -- kind of terrified of git there, though I hear it works for others.) In particular for bots that are not committing, I see no catch, other than that they will be behind whenever git.webkit.org is behind. The current git svn fetch is *super* slow. Especially if you're behind by more than a day or two. If there was a way to make this faster method safe, by wrapping it in some other (error-checking) command which knew how to fall back to git svn rebase, etc. when necessary I would love to make it the default method for all WebKit get users. I have instructed all Chrome git users to use this method since (checking the commit history...) Feb 2009 and it seems to work for us. Note that you need git = 1.6.1 or so for it to work properly. I also use this method for working on WebKit (though I've only committed around 60 patches so I mostly use it for pulling down new code). PS: our tools also run svn dcommit with --no-rebase to avoid needlessly going out to svn again after committing. ___ 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] Faster Git SVN updates
I am of the impression that now any git user need only run: git config --replace-all svn-remote.svn.fetch trunk:refs/remotes/origin/master in their get repo and updates will be faster. I'm doing so now on the EWS bots, and will fix any tooling issues in encounter. I think it's time that we consider adding a git section to http://webkit.org/building/checkout.html. -eric On Tue, Nov 30, 2010 at 2:20 PM, Eric Seidel e...@webkit.org wrote: I've now posted a patch to fix update-webkit as well: https://bugs.webkit.org/show_bug.cgi?id=50273 Once that lands, I'll move the EWS bots over to using this new setup. Assuming those stay working, we can teach the tools to offer to fix old setups. -eric On Mon, Nov 22, 2010 at 4:58 PM, Ojan Vafai o...@chromium.org wrote: http://trac.webkit.org/changeset/72575 for having scm.py do the right thing. On Thu, Nov 18, 2010 at 4:11 PM, Eric Seidel e...@webkit.org wrote: OK. Sounds we should make this setup default. I'll see if we can't educate update-webkit and webkitpy/common/checkout/scm.py about detecting this setup and doing the right thing in that case. I'll file a separate bug about making scm.py's Git object use --no-rebase during dcommit. -eric On Thu, Nov 18, 2010 at 4:08 PM, Evan Martin e...@chromium.org wrote: On Thu, Nov 18, 2010 at 3:36 PM, David Levin le...@google.com wrote: It's some magical setup by which your git svn fetchs will be much faser. But I've heard it's buggy? Can lead to local repository corruption? Can someone set me straight? No magic, just standard git: complicated, but logical once you understand how it works. :\ It means that both git pull and git svn fetch will be updating the same branch. When the latter sees the former has pulled down new stuff (quickly, via the fast git protocol), it knows to rebuild its metadata from the new stuff you fetched (rather than fetching it all over again via the slow svn protocol). There's a catch: if you git svn fetch, that creates new commits locally. When you later git pull, you get the commits that were constructed by git.webkit.org, which don't match (due to differing timestamps). This may screw up rebase, but I believe it's smart enough to recognize the commits are the same (applied the same diff; in git jargon, they have the same patch-id). In practice you don't even run git svn fetch except when the git server is behind, so I don't know if there are corner cases here that I haven't run into. (I also haven't tried this on Windows in a while -- kind of terrified of git there, though I hear it works for others.) In particular for bots that are not committing, I see no catch, other than that they will be behind whenever git.webkit.org is behind. The current git svn fetch is *super* slow. Especially if you're behind by more than a day or two. If there was a way to make this faster method safe, by wrapping it in some other (error-checking) command which knew how to fall back to git svn rebase, etc. when necessary I would love to make it the default method for all WebKit get users. I have instructed all Chrome git users to use this method since (checking the commit history...) Feb 2009 and it seems to work for us. Note that you need git = 1.6.1 or so for it to work properly. I also use this method for working on WebKit (though I've only committed around 60 patches so I mostly use it for pulling down new code). PS: our tools also run svn dcommit with --no-rebase to avoid needlessly going out to svn again after committing. ___ 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] Faster Git SVN updates
On Tue, Nov 30, 2010 at 2:59 PM, Eric Seidel e...@webkit.org wrote: I think it's time that we consider adding a git section to http://webkit.org/building/checkout.html. +1 Anecdotally, I imagine there are more webkit developers using git now than svn. -eric On Tue, Nov 30, 2010 at 2:20 PM, Eric Seidel e...@webkit.org wrote: I've now posted a patch to fix update-webkit as well: https://bugs.webkit.org/show_bug.cgi?id=50273 Once that lands, I'll move the EWS bots over to using this new setup. Assuming those stay working, we can teach the tools to offer to fix old setups. -eric On Mon, Nov 22, 2010 at 4:58 PM, Ojan Vafai o...@chromium.org wrote: http://trac.webkit.org/changeset/72575 for having scm.py do the right thing. On Thu, Nov 18, 2010 at 4:11 PM, Eric Seidel e...@webkit.org wrote: OK. Sounds we should make this setup default. I'll see if we can't educate update-webkit and webkitpy/common/checkout/scm.py about detecting this setup and doing the right thing in that case. I'll file a separate bug about making scm.py's Git object use --no-rebase during dcommit. -eric On Thu, Nov 18, 2010 at 4:08 PM, Evan Martin e...@chromium.org wrote: On Thu, Nov 18, 2010 at 3:36 PM, David Levin le...@google.com wrote: It's some magical setup by which your git svn fetchs will be much faser. But I've heard it's buggy? Can lead to local repository corruption? Can someone set me straight? No magic, just standard git: complicated, but logical once you understand how it works. :\ It means that both git pull and git svn fetch will be updating the same branch. When the latter sees the former has pulled down new stuff (quickly, via the fast git protocol), it knows to rebuild its metadata from the new stuff you fetched (rather than fetching it all over again via the slow svn protocol). There's a catch: if you git svn fetch, that creates new commits locally. When you later git pull, you get the commits that were constructed by git.webkit.org, which don't match (due to differing timestamps). This may screw up rebase, but I believe it's smart enough to recognize the commits are the same (applied the same diff; in git jargon, they have the same patch-id). In practice you don't even run git svn fetch except when the git server is behind, so I don't know if there are corner cases here that I haven't run into. (I also haven't tried this on Windows in a while -- kind of terrified of git there, though I hear it works for others.) In particular for bots that are not committing, I see no catch, other than that they will be behind whenever git.webkit.org is behind. The current git svn fetch is *super* slow. Especially if you're behind by more than a day or two. If there was a way to make this faster method safe, by wrapping it in some other (error-checking) command which knew how to fall back to git svn rebase, etc. when necessary I would love to make it the default method for all WebKit get users. I have instructed all Chrome git users to use this method since (checking the commit history...) Feb 2009 and it seems to work for us. Note that you need git = 1.6.1 or so for it to work properly. I also use this method for working on WebKit (though I've only committed around 60 patches so I mostly use it for pulling down new code). PS: our tools also run svn dcommit with --no-rebase to avoid needlessly going out to svn again after committing. ___ 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] Faster Git SVN updates
I'm not sure git can be the default way to checkout webkit until it's installed on the default Mac OS X install. :) -eric On Tue, Nov 30, 2010 at 3:07 PM, Ojan Vafai o...@chromium.org wrote: On Tue, Nov 30, 2010 at 2:59 PM, Eric Seidel e...@webkit.org wrote: I think it's time that we consider adding a git section to http://webkit.org/building/checkout.html. +1 Anecdotally, I imagine there are more webkit developers using git now than svn. -eric On Tue, Nov 30, 2010 at 2:20 PM, Eric Seidel e...@webkit.org wrote: I've now posted a patch to fix update-webkit as well: https://bugs.webkit.org/show_bug.cgi?id=50273 Once that lands, I'll move the EWS bots over to using this new setup. Assuming those stay working, we can teach the tools to offer to fix old setups. -eric On Mon, Nov 22, 2010 at 4:58 PM, Ojan Vafai o...@chromium.org wrote: http://trac.webkit.org/changeset/72575 for having scm.py do the right thing. On Thu, Nov 18, 2010 at 4:11 PM, Eric Seidel e...@webkit.org wrote: OK. Sounds we should make this setup default. I'll see if we can't educate update-webkit and webkitpy/common/checkout/scm.py about detecting this setup and doing the right thing in that case. I'll file a separate bug about making scm.py's Git object use --no-rebase during dcommit. -eric On Thu, Nov 18, 2010 at 4:08 PM, Evan Martin e...@chromium.orgwrote: On Thu, Nov 18, 2010 at 3:36 PM, David Levin le...@google.com wrote: It's some magical setup by which your git svn fetchs will be much faser. But I've heard it's buggy? Can lead to local repository corruption? Can someone set me straight? No magic, just standard git: complicated, but logical once you understand how it works. :\ It means that both git pull and git svn fetch will be updating the same branch. When the latter sees the former has pulled down new stuff (quickly, via the fast git protocol), it knows to rebuild its metadata from the new stuff you fetched (rather than fetching it all over again via the slow svn protocol). There's a catch: if you git svn fetch, that creates new commits locally. When you later git pull, you get the commits that were constructed by git.webkit.org, which don't match (due to differing timestamps). This may screw up rebase, but I believe it's smart enough to recognize the commits are the same (applied the same diff; in git jargon, they have the same patch-id). In practice you don't even run git svn fetch except when the git server is behind, so I don't know if there are corner cases here that I haven't run into. (I also haven't tried this on Windows in a while -- kind of terrified of git there, though I hear it works for others.) In particular for bots that are not committing, I see no catch, other than that they will be behind whenever git.webkit.org is behind. The current git svn fetch is *super* slow. Especially if you're behind by more than a day or two. If there was a way to make this faster method safe, by wrapping it in some other (error-checking) command which knew how to fall back to git svn rebase, etc. when necessary I would love to make it the default method for all WebKit get users. I have instructed all Chrome git users to use this method since (checking the commit history...) Feb 2009 and it seems to work for us. Note that you need git = 1.6.1 or so for it to work properly. I also use this method for working on WebKit (though I've only committed around 60 patches so I mostly use it for pulling down new code). PS: our tools also run svn dcommit with --no-rebase to avoid needlessly going out to svn again after committing. ___ 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] Faster Git SVN updates
Really? XCode isn't installed on the default Mac OS X install. I mean, sure, the easier it is to get started and all, but that's hardly a big hurdle. -- Dirk On Tue, Nov 30, 2010 at 3:15 PM, Eric Seidel e...@webkit.org wrote: I'm not sure git can be the default way to checkout webkit until it's installed on the default Mac OS X install. :) -eric On Tue, Nov 30, 2010 at 3:07 PM, Ojan Vafai o...@chromium.org wrote: On Tue, Nov 30, 2010 at 2:59 PM, Eric Seidel e...@webkit.org wrote: I think it's time that we consider adding a git section to http://webkit.org/building/checkout.html. +1 Anecdotally, I imagine there are more webkit developers using git now than svn. -eric On Tue, Nov 30, 2010 at 2:20 PM, Eric Seidel e...@webkit.org wrote: I've now posted a patch to fix update-webkit as well: https://bugs.webkit.org/show_bug.cgi?id=50273 Once that lands, I'll move the EWS bots over to using this new setup. Assuming those stay working, we can teach the tools to offer to fix old setups. -eric On Mon, Nov 22, 2010 at 4:58 PM, Ojan Vafai o...@chromium.org wrote: http://trac.webkit.org/changeset/72575 for having scm.py do the right thing. On Thu, Nov 18, 2010 at 4:11 PM, Eric Seidel e...@webkit.org wrote: OK. Sounds we should make this setup default. I'll see if we can't educate update-webkit and webkitpy/common/checkout/scm.py about detecting this setup and doing the right thing in that case. I'll file a separate bug about making scm.py's Git object use --no-rebase during dcommit. -eric On Thu, Nov 18, 2010 at 4:08 PM, Evan Martin e...@chromium.org wrote: On Thu, Nov 18, 2010 at 3:36 PM, David Levin le...@google.com wrote: It's some magical setup by which your git svn fetchs will be much faser. But I've heard it's buggy? Can lead to local repository corruption? Can someone set me straight? No magic, just standard git: complicated, but logical once you understand how it works. :\ It means that both git pull and git svn fetch will be updating the same branch. When the latter sees the former has pulled down new stuff (quickly, via the fast git protocol), it knows to rebuild its metadata from the new stuff you fetched (rather than fetching it all over again via the slow svn protocol). There's a catch: if you git svn fetch, that creates new commits locally. When you later git pull, you get the commits that were constructed by git.webkit.org, which don't match (due to differing timestamps). This may screw up rebase, but I believe it's smart enough to recognize the commits are the same (applied the same diff; in git jargon, they have the same patch-id). In practice you don't even run git svn fetch except when the git server is behind, so I don't know if there are corner cases here that I haven't run into. (I also haven't tried this on Windows in a while -- kind of terrified of git there, though I hear it works for others.) In particular for bots that are not committing, I see no catch, other than that they will be behind whenever git.webkit.org is behind. The current git svn fetch is *super* slow. Especially if you're behind by more than a day or two. If there was a way to make this faster method safe, by wrapping it in some other (error-checking) command which knew how to fall back to git svn rebase, etc. when necessary I would love to make it the default method for all WebKit get users. I have instructed all Chrome git users to use this method since (checking the commit history...) Feb 2009 and it seems to work for us. Note that you need git = 1.6.1 or so for it to work properly. I also use this method for working on WebKit (though I've only committed around 60 patches so I mostly use it for pulling down new code). PS: our tools also run svn dcommit with --no-rebase to avoid needlessly going out to svn again after committing. ___ 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] Faster Git SVN updates
For the record, I was just suggesting that http://webkit.org/building/checkout.html should have instructions for using both git and svn. On Tue, Nov 30, 2010 at 3:51 PM, Dirk Pranke dpra...@chromium.org wrote: Really? XCode isn't installed on the default Mac OS X install. I mean, sure, the easier it is to get started and all, but that's hardly a big hurdle. -- Dirk On Tue, Nov 30, 2010 at 3:15 PM, Eric Seidel e...@webkit.org wrote: I'm not sure git can be the default way to checkout webkit until it's installed on the default Mac OS X install. :) -eric On Tue, Nov 30, 2010 at 3:07 PM, Ojan Vafai o...@chromium.org wrote: On Tue, Nov 30, 2010 at 2:59 PM, Eric Seidel e...@webkit.org wrote: I think it's time that we consider adding a git section to http://webkit.org/building/checkout.html. +1 Anecdotally, I imagine there are more webkit developers using git now than svn. -eric On Tue, Nov 30, 2010 at 2:20 PM, Eric Seidel e...@webkit.org wrote: I've now posted a patch to fix update-webkit as well: https://bugs.webkit.org/show_bug.cgi?id=50273 Once that lands, I'll move the EWS bots over to using this new setup. Assuming those stay working, we can teach the tools to offer to fix old setups. -eric On Mon, Nov 22, 2010 at 4:58 PM, Ojan Vafai o...@chromium.org wrote: http://trac.webkit.org/changeset/72575 for having scm.py do the right thing. On Thu, Nov 18, 2010 at 4:11 PM, Eric Seidel e...@webkit.org wrote: OK. Sounds we should make this setup default. I'll see if we can't educate update-webkit and webkitpy/common/checkout/scm.py about detecting this setup and doing the right thing in that case. I'll file a separate bug about making scm.py's Git object use --no-rebase during dcommit. -eric On Thu, Nov 18, 2010 at 4:08 PM, Evan Martin e...@chromium.org wrote: On Thu, Nov 18, 2010 at 3:36 PM, David Levin le...@google.com wrote: It's some magical setup by which your git svn fetchs will be much faser. But I've heard it's buggy? Can lead to local repository corruption? Can someone set me straight? No magic, just standard git: complicated, but logical once you understand how it works. :\ It means that both git pull and git svn fetch will be updating the same branch. When the latter sees the former has pulled down new stuff (quickly, via the fast git protocol), it knows to rebuild its metadata from the new stuff you fetched (rather than fetching it all over again via the slow svn protocol). There's a catch: if you git svn fetch, that creates new commits locally. When you later git pull, you get the commits that were constructed by git.webkit.org, which don't match (due to differing timestamps). This may screw up rebase, but I believe it's smart enough to recognize the commits are the same (applied the same diff; in git jargon, they have the same patch-id). In practice you don't even run git svn fetch except when the git server is behind, so I don't know if there are corner cases here that I haven't run into. (I also haven't tried this on Windows in a while -- kind of terrified of git there, though I hear it works for others.) In particular for bots that are not committing, I see no catch, other than that they will be behind whenever git.webkit.org is behind. The current git svn fetch is *super* slow. Especially if you're behind by more than a day or two. If there was a way to make this faster method safe, by wrapping it in some other (error-checking) command which knew how to fall back to git svn rebase, etc. when necessary I would love to make it the default method for all WebKit get users. I have instructed all Chrome git users to use this method since (checking the commit history...) Feb 2009 and it seems to work for us. Note that you need git = 1.6.1 or so for it to work properly. I also use this method for working on WebKit (though I've only committed around 60 patches so I mostly use it for pulling down new code). PS: our tools also run svn dcommit with --no-rebase to avoid needlessly going out to svn again after committing. ___ 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
