date:20120309

On Fri, Mar 9, 2012 at 7:14 AM, Ashod Nakashian ashodnakash...@yahoo.comwrote:

 Can you be more specific? What do you find wanting in the git workflow
 besides the few cases raised by svn users (such as svn up that can be
 supported in update-webkit)?


I'm also annoyed by now git diff works since I almost always want git diff
master as I said in another thread. There are a number of other things I
don't like about git. Also, I think I'd prefer mercurial over git for its
saner behavior and terminologies if we're switching to a different VCS but
I'm not about to start a thread for that.

Quite frankly, moving to git will make my workflow worse regardless of
improvements... It's like forcing me to use Linux instead of Windows/Mac.
I'll do it if the overwhelming majority of the community thinks that's a
good thing but I won't be happy about it.

I think if we address the main issues raised by the svn users, the current
 consensus (if representative) seems to point towards an overwhelming
 support (and demand?) for git over svn. On that point it's reasonable to
 say that we're heading towards option #1 or #2 of Maciej. As such, I'm
 humbly proposing the following (hopefully without getting ahead of myself):


Frankly, I don't quite understand the benefit of this transition. Do we
really need to move to git? If the only problem of keeping svn was about
svn-apply being broken, I'm more than happy to fix that script.

A) Address as many of the issues raised by the svn users and streamline
 their use-cases in the current scripts on top of git that we can (this
 would leave generation numbers out of scope as it's a git issue, although
 we can push that on git's mail-list). Address any current issues that
 (advanced/seasoned) git users find wanting/missing to have a solid system
 that capitalizes on the powers of git as much as possible.


I'd argue that generation numbers is a requirement for this transition.
Monotonically increasing number is one major benefit of using svn server.
Also, ideally, this generation number will be consisnte with the existing
svn revision numbers so that if N is the last revision committed to the svn
repository then the first commit in the git repository should have the
generation number of N+1.

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

Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Konrad Piascik

Hi Ryosuke,

There are solutions in git for all of your raised issues.  If you want to have 
git diff work against master then you just need to setup an alias to do that 
for you.
http://gitready.com/intermediate/2009/02/06/helpful-command-aliases.html

This way you can create aliases for all the commands and syntax you want.

Alexis mentioned that it is possible to have a linear history that Qt uses.  It 
should also be possible to setup a git hook on the server side to modify the 
commit message and include the revision number.

-Konrad

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Ryosuke Niwa [rn...@webkit.org]
Sent: Friday, March 09, 2012 11:33 AM
To: Ashod Nakashian
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Moving to Git?

On Fri, Mar 9, 2012 at 7:14 AM, Ashod Nakashian 
ashodnakash...@yahoo.commailto:ashodnakash...@yahoo.com wrote:
Can you be more specific? What do you find wanting in the git workflow besides 
the few cases raised by svn users (such as svn up that can be supported in 
update-webkit)?

I'm also annoyed by now git diff works since I almost always want git diff 
master as I said in another thread. There are a number of other things I don't 
like about git. Also, I think I'd prefer mercurial over git for its saner 
behavior and terminologies if we're switching to a different VCS but I'm not 
about to start a thread for that.

Quite frankly, moving to git will make my workflow worse regardless of 
improvements... It's like forcing me to use Linux instead of Windows/Mac. I'll 
do it if the overwhelming majority of the community thinks that's a good thing 
but I won't be happy about it.

I think if we address the main issues raised by the svn users, the current 
consensus (if representative) seems to point towards an overwhelming support 
(and demand?) for git over svn. On that point it's reasonable to say that we're 
heading towards option #1 or #2 of Maciej. As such, I'm humbly proposing the 
following (hopefully without getting ahead of myself):

Frankly, I don't quite understand the benefit of this transition. Do we really 
need to move to git? If the only problem of keeping svn was about svn-apply 
being broken, I'm more than happy to fix that script.

A) Address as many of the issues raised by the svn users and streamline their 
use-cases in the current scripts on top of git that we can (this would leave 
generation numbers out of scope as it's a git issue, although we can push that 
on git's mail-list). Address any current issues that (advanced/seasoned) git 
users find wanting/missing to have a solid system that capitalizes on the 
powers of git as much as possible.

I'd argue that generation numbers is a requirement for this transition. 
Monotonically increasing number is one major benefit of using svn server. Also, 
ideally, this generation number will be consisnte with the existing svn 
revision numbers so that if N is the last revision committed to the svn 
repository then the first commit in the git repository should have the 
generation number of N+1.

- Ryosuke

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] img onabort=foo() ...

2012-03-09 Thread 蓋文彼德斯

I'm reading through event handling on attributes which load media as I
contemplate some changes for Link elements, and I came across a curiosity.
 The HTMLImageElement dutifully registers any onabort handler specified in
the element, but I can't find any code path that would actually launch one.
 Certainly the ImageLoader can only send onbeforeload, onload, onerror.

There also don't seem to be any LayoutTests with onabort set for an IMG.

Am I missing a path, or is this now redundant?

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

Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Kalle Vahlman

2012/3/9 Ryosuke Niwa rn...@webkit.org:
 On Fri, Mar 9, 2012 at 7:14 AM, Ashod Nakashian ashodnakash...@yahoo.com
 wrote:
 I think if we address the main issues raised by the svn users, the current
 consensus (if representative) seems to point towards an overwhelming support
 (and demand?) for git over svn. On that point it's reasonable to say that
 we're heading towards option #1 or #2 of Maciej. As such, I'm humbly
 proposing the following (hopefully without getting ahead of myself):


 Frankly, I don't quite understand the benefit of this transition. Do we
 really need to move to git? If the only problem of keeping svn was about
 svn-apply being broken, I'm more than happy to fix that script.

I think you missed the part where the impact on servers was discussed.
If every time someone does svn log the server needs to not receive
or deal out commits, it will show in response times. I'm sure people
using svn do not check the log often, for obvious reasons, but it is
still a factor to consider.

-- 
Kalle Vahlman, z...@iki.fi
Powered by http://movial.com
Interesting stuff at http://sandbox.movial.com
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Moving to Git?

On Fri, 2012-03-09 at 08:33 -0800, Ryosuke Niwa wrote:

 Frankly, I don't quite understand the benefit of this transition. Do
 we really need to move to git? If the only problem of keeping svn was
 about svn-apply being broken, I'm more than happy to fix that script.

For me the biggest benefit would be to do away with ChangeLog files, if
we come to that by moving to git. I'm otherwise happy with using the git
mirror and git svn for all my needs.

Cheers,


-- 
Gustavo Noronha Silva g...@gnome.org
GNOME Project

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

Re: [webkit-dev] Moving to Git?

On Thu, 2012-03-08 at 19:39 -0300, Alexis Menard wrote:
  To svn user :
  - Conflict resolving much easier and performant than svn (we have
  drivers for changelogs and the default one are much better than svn).
  - Local history/blaming/...
  - Proper diff coloration (though I'm sure you guys have some magic
  scripts using colordiff).
  - The staging area, upload what you want/need and keep some work local
  - Smaller checkouts
 
 - Bot maintainers :
 Power outage or network interruption in the middle of a svn
 checkout/up lock the repo sometimes and you need to manually svn
 cleanup the checkout (maybe someone have a tool or script to avoid
 that???). I had much more svn locked repos than git dead checkout
 because of interruptions.

/me puts his bot maintainer hat on

That does suck indeed. Been a while since I had to manually intervene,
but even when it is fixed automatically, the new checkout takes ages
(because the automatic fix is to rm -rf the whole source tree).

That said, we don't need to change the main repository to have bots use
git - we can use a git mirror for most bot needs without changing the
main repository.

Cheers,

-- 
Gustavo Noronha Silva g...@gnome.org
GNOME Project

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

Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Mark Rowe


On 2012-03-09, at 10:23, Gustavo Noronha Silva g...@gnome.org wrote:

 On Thu, 2012-03-08 at 19:39 -0300, Alexis Menard wrote:
 To svn user :
 - Conflict resolving much easier and performant than svn (we have
 drivers for changelogs and the default one are much better than svn).
 - Local history/blaming/...
 - Proper diff coloration (though I'm sure you guys have some magic
 scripts using colordiff).
 - The staging area, upload what you want/need and keep some work local
 - Smaller checkouts
 
 - Bot maintainers :
 Power outage or network interruption in the middle of a svn
 checkout/up lock the repo sometimes and you need to manually svn
 cleanup the checkout (maybe someone have a tool or script to avoid
 that???). I had much more svn locked repos than git dead checkout
 because of interruptions.
 
 /me puts his bot maintainer hat on
 
 That does suck indeed. Been a while since I had to manually intervene,
 but even when it is fixed automatically, the new checkout takes ages
 (because the automatic fix is to rm -rf the whole source tree).

The solution for this would be to teach buildbot run 'svn cleanup' when 
necessary rather than just assuming the worst and nuking the working copy. This 
will become trivial to do in future versions of Buildbot as they're moving the 
logic for how version control operations to the server rather than the slaves, 
meaning it becomes much easier to update and customize.

- Mark

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

Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Mark Rowe


On 2012-03-09, at 09:15, Kalle Vahlman kalle.vahl...@gmail.com wrote:

 2012/3/9 Ryosuke Niwa rn...@webkit.org:
 On Fri, Mar 9, 2012 at 7:14 AM, Ashod Nakashian ashodnakash...@yahoo.com
 wrote:
 I think if we address the main issues raised by the svn users, the current
 consensus (if representative) seems to point towards an overwhelming support
 (and demand?) for git over svn. On that point it's reasonable to say that
 we're heading towards option #1 or #2 of Maciej. As such, I'm humbly
 proposing the following (hopefully without getting ahead of myself):
 
 
 Frankly, I don't quite understand the benefit of this transition. Do we
 really need to move to git? If the only problem of keeping svn was about
 svn-apply being broken, I'm more than happy to fix that script.
 
 I think you missed the part where the impact on servers was discussed.
 If every time someone does svn log the server needs to not receive
 or deal out commits, it will show in response times. I'm sure people
 using svn do not check the log often, for obvious reasons, but it is
 still a factor to consider.

Making operations like 'log' not hit the server would obviously be nice, but 
the vast majority of the load on the Subversion server is from update or 
checkout operations.  Do you have a pointer to any concrete data about the 
relative load on a server for Git vs Subversion in terms of these operations?

Thanks,

- Mark


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

Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Mark Rowe

On 2012-03-09, at 07:14, Ashod Nakashian ashodnakash...@yahoo.com wrote:

 From: David Barr davidb...@google.com
 To: Ryosuke Niwa rn...@webkit.org 
 Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org 
 Sent: Friday, March 9, 2012 2:37 AM
 Subject: Re: [webkit-dev] Moving to Git?

 I think we ought to streamline the git workflow before we start trying
 to proselytise Subversion users. :)

 Can you be more specific? What do you find wanting in the git workflow 
 besides the few cases raised by svn users (such as svn up that can be 
 supported in update-webkit)?

 I think if we address the main issues raised by the svn users, the current 
 consensus (if representative) seems to point towards an overwhelming support 
 (and demand?) for git over svn.

What you'll find is that the vast majority of SVN users are simply not 
participating in this email thread. You'll also find that many people that use 
git-svn are happy enough with the status quo since it gives those who chose to 
use it most of the benefits of a pure Git setup without forcing it on others.

In my opinion a substantial benefit needs to be demonstrated in order to 
convince the existing SVN users, many of which are substantial long-term 
contributors to the project, that it's worth it to them to relearn how to 
contribute to WebKit. And I do feel that SVN users need to want to switch to 
Git in order for it to be worth pursuing such a switch. As a heavy Git user 
myself I've not seen any arguments in this thread that would be convincing to 
someone not already familiar with Git.

- Mark

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

Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Maciej Stachowiak


Here's my thoughts based on this and other comments

On Mar 8, 2012, at 2:30 PM, Alexis Menard wrote:

 
 To the global infrastructure :
 - Local history for git. svn log access to the server every time you
 call that command. Will improve the load of the server.
 - Performance of checkouts/pull as data are send compressed from the server.

Sounds like there is some potential benefit here, though we might want to 
explore beefing up the servers before changing the tools.

 
 To git user :
 - Using git push rather than having to use git-svn (which you need to
 keep in sync).
 - Simplified workflow, we don't need to mess with git-svn.
 - Companies who fork (we all do) can simplify their workflow a bit
 regarding branches.

It sounds like avoiding use of git-svn is the big benefit to git users and 
perhaps the reason this topic periodically comes up. Can anyone spell out in 
more detail the benefits of using straight git instead of git-svn?

 
 To svn user :
 - Conflict resolving much easier and performant than svn (we have
 drivers for changelogs and the default one are much better than svn).
 - Local history/blaming/...
 - Proper diff coloration (though I'm sure you guys have some magic
 scripts using colordiff).
 - The staging area, upload what you want/need and keep some work local
 - Smaller checkouts

So far many SVN users haven't found these benefits to exceed the switching 
cost, though perhaps more will be inspired to give git a try by this thread.

Regards,
aciek

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

Re: [webkit-dev] exporting symbols for building .so/.dll's

2012-03-09 Thread Ami Fischman

Thanks for your reply, Morrita!

For ports on approach C, it doesn't matter which WebCore/JSC API is

used from WebKit API layer because they are built in the same library.

If you mean that nothing in WebCore/JSC needs to be annotated as exported
then I don't think that's right, because libwebkit.so has various other
libwebcore_*.a's linked into it.
E.g. if I revert the change I made to
JavaScriptCore/wtf/chromium/ChromiumThreading.h to *not*
have ChromiumThreading be declared WTF_EXPORT, then the link of
webkit_unit_tests fails because libwtf.a
(JavaScriptCore/wtf/chromium/MainThreadChromium.cpp) contains a call to
WTF::ChromiumThreading::callOnMainThread which is a hidden symbol in
libwebkit.so (WebKit/chromium/src/ChromiumThreading.cpp).
Maybe I misunderstood your point?

For JSC API, which A and B folks care about, there are two ways to
export it.
- For Windows port, there is JavaScriptCore.def.
- For Mac (and WX?) port, there are macro-based annotations like
JS_EXPORT, WTF_EXPORT_PRIVATE.
I'm in the way to eliminate JavaScriptCore.def by replacing it with these
annotations, but the migration isn't finished yet. (http://wkb.ug/76257)

Yay.

For WebCore API, we only need to care about WebCore.exp.in because Mac
port is the only one which follows A pattern. (I remember Windows
port used to use this pattern. But it looks no longer the case. Maybe
they changed the way when they switched to WebKit2. But my memory
might be just wrong...)

I'm curious whether you have plans (or know of others' plans) to replace
WebCore.exp.in in favor of macros, like you did in http://webk.it/72854 for
JavaScriptCore.exp.

My personal preference is to introduce WebCore version of export
macros like WK_EXPORT_PRIVATE. In this way, we could use it to get rid
of WebCore.exp.in in the future.

Isn't that what
WEBKIT_EXPORTDATAhttp://cs/#chrome/src/third_party/WebKit/Source/WebCore/platform/PlatformExportMacros.hq=file:WebCore/platform/PlatformExportMacros.h%20WEBKIT_EXPORTDATAl=39
already
is? (contrary to the macro's name, it lives in WebCore; perhaps it is
trickier than I realize and somehow only applies to WebKit code even though
it lives in WebCore? Or maybe it just needs to be renamed?)

Yet another approach could be just giving up to have the unit test as a
separate binary and build it into the library for non-prod
configuration. The last one seems exactly what you are trying to avoid
though...

Right; linking test code into the main library is what HEAD does now.

Anyway, I'd like to hear thoughts from other folks.

Me too. As someone pointed out to me, others might be too busy with the
git thread to reply to this one :)

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

Re: [webkit-dev] exporting symbols for building .so/.dll's

2012-03-09 Thread Dirk Pranke

On Thu, Mar 8, 2012 at 7:52 PM, Ami Fischman fisch...@chromium.org wrote:
 Hi webkittens,

 The over-all question: how should webkit libraries declare which symbols
 they export?
 The trigger for the question: as described in bug 80062, the chromium
 shared-library-based build links test code into the (non-test) libwebkit.so
 target, which is terrible.

 The details:
 I took a crack at fixing the above bug (see patch in the bug) by pulling the
 test files out of the non-test build target, and sprinkling various
 {WTF,WEBKIT}_EXPORT{,DATA} macros around declarations that need them (as
 discovered by build-time and run-time failures).  This style of export
 declaration is what the webkit codebase does in various places
 (WTF, Platform, WebCore, and WebKit, AFAICT), and incidentally also what
 the chromium project uses for its sub-components.
 But I'm told other ports use different mechanisms such as .exp.in files for
 apple/mac (and maybe others for other ports? IDK).

 Is there consensus on the list for what the Right Thing To Do(tm) is?
 ISTM my options are:
 1) Add EXPORT declarations as in the patch on the bug.
 2) Drop the patch from the bug and replace it with chromium-specific
 .exp.in-style files, one per layer from which I need to export (WebCore,
 WTF, WebKit).  And build the build-time machinery to use them.  I don't
 really know what's involved here and would appreciate any pointers/hints
 people had if this is the way to go.
 3) Something else (preferably unifying other ports' approaches).


I haven't really done much with the export macros in WebKit, but I
have had plenty of experience w/ this stuff in Chromium ...

As far as I know, if you take the EXPORT macro approach you should be
able to build everywhere; i.e., there's no platform I'm aware of that
requires .def / .exp files. If there was, I would hope that we could
generate those from the annotated source.

In addition, the EXPORT macros have the benefit (at least, I think
it's a benefit) of being in the source file, so it's one less place to
look and one less thing to keep in sync. I believe overall maintenance
is lowest this way.

So, my preference would be to use EXPORT macros.

I believe the fact that different ports carve up the components
differently can be addressed through the proper definition of the
macros (we do this in Chromium today, as you probably know).

The whole this symbol only needs to be exported for testing purposes
problem is somewhat orthogonal and I don't know of a good solution to
this; either you export more than you want, or you have to link test
code into the library, or your test build is different from your
release build :(.

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

Re: [webkit-dev] exporting symbols for building .so/.dll's

On Thu, Mar 8, 2012 at 10:32 PM, Hajime Morrita morr...@chromium.orgwrote:

 My personal preference is to introduce WebCore version of export
 macros like WK_EXPORT_PRIVATE. In this way, we could use it to get rid
 of WebCore.exp.in in the future.


That sounds like a good idea. I hate having to figure out mangled symbol
names. But let's not use abbreviations like WK. Also, it's symbol exports
from WebCore so I'd prefer calling it WEBCORE_EXPORT.

Another possibility is to ride existing WebCore.exp.in somehow.


But mangled symbol names will be different on different platforms so I
don't think that's a good idea.

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

[webkit-dev] Test conversion to use W3C testharness.js

I recently uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=80709 
which converted an existing JavaScript regions parsing test to use the W3C 
testharness.js in place of js-test-pre.js/js-test-post.js.  This patch also 
places testharness.js and a WebKit-specific testharnessreport.js file in 
LayoutTests/fast/js/resources.

In cases where tests need to be written for both the WebKit and W3C testing 
suites, having the ability to use testharness.js with WebKit tests would mean 
that the test file only needs to be written once, and yet can still rely on the 
functionality from both test harnesses.   As it stands now, if someone needs to 
write a test for both suites, they either have to implement all functionality 
from scratch, or write one version of the test to use js-test-pre.js and 
another to use testharness.js.  The inclusion of testharness.js in the WebKit 
repository alleviates the need for this duplication of effort.  The 
testharnessreport.js file was intended for customization of the capabilities 
provided by testharness.js, I've added a call to 
layoutTestController.dumpAsText() to this file to allow it to function as a 
WebKit JavaScript test.

There is some potential issues that I wanted feedback on.

testharness.js uses a css file to format the test output.  The path to this css 
file is assembled by the script.  For the time being, I have not included the 
css file in the patch I attached to 80709.  The CSS file has no impact when 
testharness.js is used along with dumpAsText as I have in the test I converted. 
 It may provide some value, but I am going to suggest to the W3C that the CSS 
styling of results should move from testharness.js to testharnessreport.js 
(where it can be overridden).

Another concern is that changes to testharness.js in the future that break 
backward compatibility could then break WebKit tests.  This is an issue I plan 
to discuss with W3C members to determine if backward compatibility can be 
ensured.

I'd appreciate any thoughts or feedback people have on this issue.

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

Re: [webkit-dev] Test conversion to use W3C testharness.js

On Fri, Mar 9, 2012 at 2:28 PM, Jacob Goldstein jac...@adobe.com wrote:

 I recently uploaded a patch to
 https://bugs.webkit.org/show_bug.cgi?id=80709 which converted an existing
 JavaScript regions parsing test to use the W3C testharness.js in place of
 js-test-pre.js/js-test-post.js.  This patch also places testharness.js
 and a WebKit-specific testharnessreport.js file in
 LayoutTests/fast/js/resources.


Can we put them in LayoutTests/resources instead? I always find it hard to
remember the path fast/js/resources.

In cases where tests need to be written for both the WebKit and W3C testing
 suites, having the ability to use testharness.js with WebKit tests would
 mean that the test file only needs to be written once, and yet can still
 rely on the functionality from both test harnesses.   As it stands now, if
 someone needs to write a test for both suites, they either have to
 implement all functionality from scratch, or write one version of the test
 to use js-test-pre.js and another to use testharness.js.  The inclusion of
 testharness.js in the WebKit repository alleviates the need for this
 duplication of effort.  The testharnessreport.js file was intended for
 customization of the capabilities provided by testharness.js, I've added a
 call to layoutTestController.dumpAsText() to this file to allow it to
 function as a WebKit JavaScript test.


I support the effort to make layout tests more compatible with W3C tests.

Is the plan to use testharness.js for all new tests? Or only tests that we
intend to contribute back to W3C?

Another concern is that changes to testharness.js in the future that break
 backward compatibility could then break WebKit tests.  This is an issue I
 plan to discuss with W3C members to determine if backward compatibility can
 be ensured.


There is no such a guarantee at the moment? That concerns me. On other
hand, we wouldn't be importing ToT version of testharness.js so if such an
incompatibility is introduced, we can migrate our tests on time as well.

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

Re: [webkit-dev] Test conversion to use W3C testharness.js

2012-03-09 Thread Alan Stearns

I’m told that changes to the file are meant to be backwards-compatible. The API 
should not change, except to add new methods.


On 3/9/12 2:28 PM, Jacob Goldstein jac...@adobe.com wrote:

I recently uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=80709 
which converted an existing JavaScript regions parsing test to use the W3C 
testharness.js in place of js-test-pre.js/js-test-post.js.  This patch also 
places testharness.js and a WebKit-specific testharnessreport.js file in 
LayoutTests/fast/js/resources.

In cases where tests need to be written for both the WebKit and W3C testing 
suites, having the ability to use testharness.js with WebKit tests would mean 
that the test file only needs to be written once, and yet can still rely on the 
functionality from both test harnesses.   As it stands now, if someone needs to 
write a test for both suites, they either have to implement all functionality 
from scratch, or write one version of the test to use js-test-pre.js and 
another to use testharness.js.  The inclusion of testharness.js in the WebKit 
repository alleviates the need for this duplication of effort.  The 
testharnessreport.js file was intended for customization of the capabilities 
provided by testharness.js, I've added a call to 
layoutTestController.dumpAsText() to this file to allow it to function as a 
WebKit JavaScript test.

There is some potential issues that I wanted feedback on.

testharness.js uses a css file to format the test output.  The path to this css 
file is assembled by the script.  For the time being, I have not included the 
css file in the patch I attached to 80709.  The CSS file has no impact when 
testharness.js is used along with dumpAsText as I have in the test I converted. 
 It may provide some value, but I am going to suggest to the W3C that the CSS 
styling of results should move from testharness.js to testharnessreport.js 
(where it can be overridden).

Another concern is that changes to testharness.js in the future that break 
backward compatibility could then break WebKit tests.  This is an issue I plan 
to discuss with W3C members to determine if backward compatibility can be 
ensured.

I'd appreciate any thoughts or feedback people have on this issue.

Thanks,
Jacob

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

Re: [webkit-dev] About BrowsingContext and WindowProxy spec

2012-03-09 Thread Sam Weinig


On Mar 7, 2012, at 9:25 PM, Darin Adler wrote:

 On Mar 7, 2012, at 9:34 AM, Adam Barth wrote:
 
 The WindowProxy is implemented in WebKit using the WindowShell class.
 
 Idle thought: We might want to consider renaming our WindowShell class 
 WindowProxy, just to match the HTML specification concept, as I think we’ve 
 done in a few other cases.
 
 -- Darin

Yeah, we should do that.  Filed https://bugs.webkit.org/show_bug.cgi?id=80733.

-Sam

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

Re: [webkit-dev] Moving to Git?

On Fri, 2012-03-09 at 13:43 -0800, Maciej Stachowiak wrote:
  - Simplified workflow, we don't need to mess with git-svn.
  - Companies who fork (we all do) can simplify their workflow a bit
  regarding branches.
 
 It sounds like avoiding use of git-svn is the big benefit to git users
 and perhaps the reason this topic periodically comes up. Can anyone
 spell out in more detail the benefits of using straight git instead of
 git-svn?

I am a git user, I use git-svn for all my commits and I tend to use git
for every project I create myself outside of WebKit. I see lots of
benefits to using git over svn. However, for a project like WebKit I
think there's really no reason to use git other than people feeling good
about removing git-svn from their systems.

I tend to think there is little or no benefit to switching to git while
keeping all of the project workflow in place. The fact that we would
want to keep a simple history with no merges in it pretty much defeat
any benefit that could be had. I think using git only makes sense if we
adopt git workflows, which would mean people would post git branches
for review instead of patches, and those branches would then get merged.

The one point I think makes a lot of sense to investigate is tools.
People who are maintaining the awesome tools we use today have been
doing a great job of making them work for both git and svn users, but
it's probably a big burden for them. So, if people declare that some
tools will only work with git work directories, I'd be fine with it,
would anyone oppose? We can keep using svn as the central server, but
people wanting to use those tools would have to use git-svn.

Tbh, I am much more interested in doing away with ChangeLogs than in
feeling good about using git push instead of git svn dcommit. If we
could find a way around ChangeLogs while keeping svn, then I would be an
even happier panda than I am today =).

Cheers,

-- 
Gustavo Noronha Silva g...@gnome.org
GNOME Project

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

Re: [webkit-dev] Is converting pixel tests to reftests kosher for imported libraries?

2012-03-09 Thread Sam Weinig


On Mar 7, 2012, at 4:41 PM, Ojan Vafai wrote:

 I just did a first pass a greening the Chromium Lion bot: 
 http://trac.webkit.org/changeset/110096. Of these hundreds of tests,  ~99% of 
 them are perfect candidates for being reftests (e.g. they contain one line of 
 text and a solid box or two under the text), but most of them are in the CSS 
 imported test suites.
 
 Is it kosher to convert them to reftests or should we leave pixel tests from 
 imported test suites alone?

If we want to make these ref tests, it probably makes more sense to do that 
work with the CSS WG, so that they can be part of the standard test suite. 
Until then, I think we should keep them regular pixel tests.

-Sam

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

Re: [webkit-dev] Moving to Git?

2012-03-09 Thread noam . rosenthal


On Mar 9, 2012, at 1:43 PM, ext Maciej Stachowiak wrote:

It sounds like avoiding use of git-svn is the big benefit to git users and 
perhaps the reason this topic periodically comes up. Can anyone spell out in 
more detail the benefits of using straight git instead of git-svn?

My main pain point with the current workflow, which can potentially be repaired 
by using a real git workflow, is the manual changelog editing, rather than 
using commit messages.
With a git workflow we can review commit messages as part of the regular review 
process, which I understand we can't do with SVN (though I don't know SVN that 
well).

Wouldn't a world without manual changelog editing be slightly nicer?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Emil A Eklund

On Fri, Mar 9, 2012 at 14:46, Adam Treat atr...@rim.com wrote:
 Would be good to know who the remaining svn users are.  And who is using 
 git/git-svn now.  I'd love to see the breakdown.  Data is good.

I'm another svn user and while I'd prefer to keep using svn I'm not
opposed to migrating to git if that is what the majority wants.
Maintaining both certainly seems undesirable in the long run.

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

Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Geoffrey Garen

I'm starting to see a mathematical relationship between
(a) Volume of contribution to the WebKit OpenSource Project
(b) Volume of advocacy for removing svn support from the WebKit OpenSource 
Project

The relationship seems to be of the inverse variety.

In your case, Ashod:

Source find . -name ChangeLog\* | xargs grep Nakashian | wc -l
   2

Geoff

On Mar 9, 2012, at 7:14 AM, Ashod Nakashian wrote:

 I think if we address the main issues raised by the svn users, the current 
 consensus (if representative) seems to point towards an overwhelming support 
 (and demand?) for git over svn. On that point it's reasonable to say that 
 we're heading towards option #1 or #2 of Maciej. As such, I'm humbly 
 proposing the following (hopefully without getting ahead of myself):
 
 A) Address as many of the issues raised by the svn users and streamline their 
 use-cases in the current scripts on top of git that we can (this would leave 
 generation numbers out of scope as it's a git issue, although we can push 
 that on git's mail-list). Address any current issues that (advanced/seasoned) 
 git users find wanting/missing to have a solid system that capitalizes on the 
 powers of git as much as possible.
 
 B) Plan a phase-out schedule for svn repo, servers and scripts and mainlining 
 git (this needs input from ops and those who can assess the overhead involved 
 - something I'm ignorant of). Offer the option of having svn mirror (however 
 realistic that is, I can't tell) keeping in mind the overhead of maintaining 
 the svn scripts.
 
 If we don't do anything we'll be supporting both systems, scripts, docs etc. 
 with little advantage but having the choice of both systems (status-quo). If 
 we start moving towards git I think we'll end up with the reverse situation 
 than what we have now (git mainline, svn mirror) and, assuming the majority 
 use git and there are more benefits to git over svn, then WebKit will benefit 
 more that way than the case is now. However, having said that, something 
 tells me the remaining svn users will probably switch to git sooner rather 
 than later.
 
 (Disclaimer: I enjoy svn as much as the next guy, but I think git offers 
 enough power to justify the overhead of learning/adapting/migrating to it. In 
 addition, as many pointed out, no one has to use all the power features and 
 the svn-equivalent day-to-day ones can be automated transparently by current 
 (and new) scripts.)
 
 -Ash


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

Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Pablo Flouret

On Fri, 09 Mar 2012 14:47:17 -0800, Gustavo Noronha Silva g...@gnome.org  
wrote:



I tend to think there is little or no benefit to switching to git while
keeping all of the project workflow in place. The fact that we would
want to keep a simple history with no merges in it pretty much defeat
any benefit that could be had. I think using git only makes sense if we
adopt git workflows, which would mean people would post git branches
for review instead of patches, and those branches would then get merged.


I agree.
I've lived through a large-scale git migration (from CVS, though, so it  
had literally zero opposition from people, the big issue was  
infrastructure constraints), and one of the greatest benefits was the  
breadth of workflows git allows to choose from, so if people are mostly  
happy with the current workflow, then if it ain't broke, don't fix it  
probably applies.


Otherwise, the question might be how much easier would it be to experiment  
with new workflows if we got rid of subversion altogether. Or if people  
want to think about new workflows at all, for that matter.




Tbh, I am much more interested in doing away with ChangeLogs than in
feeling good about using git push instead of git svn dcommit. If we
could find a way around ChangeLogs while keeping svn, then I would be an
even happier panda than I am today =).


+1

--
pablo flouret
motorola | webkit / browser team
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Test conversion to use W3C testharness.js

LayoutTests/resources is fine with me – that was the location I considered 
using originally and only moved them to LayoutTests/fast/js/resources because 
that is where js-test-pre and –post are.

I'll upload a new patch with the files in LayoutTests/resources.

From: Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org
Date: Fri, 9 Mar 2012 14:37:18 -0800
To: Jacob Goldstein jac...@adobe.commailto:jac...@adobe.com
Cc: webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org 
webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Test conversion to use W3C testharness.js

On Fri, Mar 9, 2012 at 2:28 PM, Jacob Goldstein 
jac...@adobe.commailto:jac...@adobe.com wrote:
I recently uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=80709 
which converted an existing JavaScript regions parsing test to use the W3C 
testharness.js in place of js-test-pre.js/js-test-post.js.  This patch also 
places testharness.js and a WebKit-specific testharnessreport.js file in 
LayoutTests/fast/js/resources.

Can we put them in LayoutTests/resources instead? I always find it hard to 
remember the path fast/js/resources.

In cases where tests need to be written for both the WebKit and W3C testing 
suites, having the ability to use testharness.js with WebKit tests would mean 
that the test file only needs to be written once, and yet can still rely on the 
functionality from both test harnesses.   As it stands now, if someone needs to 
write a test for both suites, they either have to implement all functionality 
from scratch, or write one version of the test to use js-test-pre.js and 
another to use testharness.js.  The inclusion of testharness.js in the WebKit 
repository alleviates the need for this duplication of effort.  The 
testharnessreport.js file was intended for customization of the capabilities 
provided by testharness.js, I've added a call to 
layoutTestController.dumpAsText() to this file to allow it to function as a 
WebKit JavaScript test.

I support the effort to make layout tests more compatible with W3C tests.

Is the plan to use testharness.js for all new tests? Or only tests that we 
intend to contribute back to W3C?

Another concern is that changes to testharness.js in the future that break 
backward compatibility could then break WebKit tests.  This is an issue I plan 
to discuss with W3C members to determine if backward compatibility can be 
ensured.

There is no such a guarantee at the moment? That concerns me. On other hand, we 
wouldn't be importing ToT version of testharness.js so if such an 
incompatibility is introduced, we can migrate our tests on time as well.

- Ryosuke

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

Re: [webkit-dev] Test conversion to use W3C testharness.js

I looked at the patch you uploaded, but it wasn't clear from the text
dump whether the subtests passed or failed.  Maybe testharness.js uses
a table and/or colors to present that information?  It's important
that we can easily determine which subtests pass or fail from a text
dump.

Adam


On Fri, Mar 9, 2012 at 3:19 PM, Jacob Goldstein jac...@adobe.com wrote:
 LayoutTests/resources is fine with me – that was the location I considered
 using originally and only moved them to LayoutTests/fast/js/resources
 because that is where js-test-pre and –post are.

 I'll upload a new patch with the files in LayoutTests/resources.



 From: Ryosuke Niwa rn...@webkit.org
 Date: Fri, 9 Mar 2012 14:37:18 -0800
 To: Jacob Goldstein jac...@adobe.com
 Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] Test conversion to use W3C testharness.js

 On Fri, Mar 9, 2012 at 2:28 PM, Jacob Goldstein jac...@adobe.com wrote:

 I recently uploaded a patch
 to https://bugs.webkit.org/show_bug.cgi?id=80709 which converted an existing
 JavaScript regions parsing test to use the W3C testharness.js in place of
 js-test-pre.js/js-test-post.js.  This patch also places testharness.js and a
 WebKit-specific testharnessreport.js file in LayoutTests/fast/js/resources.


 Can we put them in LayoutTests/resources instead? I always find it hard to
 remember the path fast/js/resources.

 In cases where tests need to be written for both the WebKit and W3C
 testing suites, having the ability to use testharness.js with WebKit tests
 would mean that the test file only needs to be written once, and yet can
 still rely on the functionality from both test harnesses.   As it stands
 now, if someone needs to write a test for both suites, they either have to
 implement all functionality from scratch, or write one version of the test
 to use js-test-pre.js and another to use testharness.js.  The inclusion of
 testharness.js in the WebKit repository alleviates the need for this
 duplication of effort.  The testharnessreport.js file was intended for
 customization of the capabilities provided by testharness.js, I've added a
 call to layoutTestController.dumpAsText() to this file to allow it to
 function as a WebKit JavaScript test.


 I support the effort to make layout tests more compatible with W3C tests.

 Is the plan to use testharness.js for all new tests? Or only tests that we
 intend to contribute back to W3C?

 Another concern is that changes to testharness.js in the future that break
 backward compatibility could then break WebKit tests.  This is an issue I
 plan to discuss with W3C members to determine if backward compatibility can
 be ensured.


 There is no such a guarantee at the moment? That concerns me. On other hand,
 we wouldn't be importing ToT version of testharness.js so if such an
 incompatibility is introduced, we can migrate our tests on time as well.

 - Ryosuke


 ___
 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] Test conversion to use W3C testharness.js

I replied to your comment in the bug, but will also copy below
-

I understand your concern.  Some of this is user defined, and the output
could also be improved via customizations to the testharnessreport.js file.

The message you see after Pass, for example, testParse: Assigned none
to property, expected return = none, is the user defined string from the
description argument of the assert_equals method.   assert_equals looks
like this:

assert_equals(actual, expected, description)

All of the methods in testharness.js include a description argument that
is output after the test result.  In the W3C test suite, the
testharness.css file formats the output into a slightly more readable
output.  Since we are dumping as text, that isn't possible, but other
customizations in testharnessreport.js are.  I will look into this further.





On 3/9/12 3:21 PM, Adam Barth aba...@webkit.org wrote:

I looked at the patch you uploaded, but it wasn't clear from the text
dump whether the subtests passed or failed.  Maybe testharness.js uses
a table and/or colors to present that information?  It's important
that we can easily determine which subtests pass or fail from a text
dump.

Adam


On Fri, Mar 9, 2012 at 3:19 PM, Jacob Goldstein jac...@adobe.com wrote:
 LayoutTests/resources is fine with me  that was the location I
considered
 using originally and only moved them to LayoutTests/fast/js/resources
 because that is where js-test-pre and post are.

 I'll upload a new patch with the files in LayoutTests/resources.



 From: Ryosuke Niwa rn...@webkit.org
 Date: Fri, 9 Mar 2012 14:37:18 -0800
 To: Jacob Goldstein jac...@adobe.com
 Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] Test conversion to use W3C testharness.js

 On Fri, Mar 9, 2012 at 2:28 PM, Jacob Goldstein jac...@adobe.com
wrote:

 I recently uploaded a patch
 to https://bugs.webkit.org/show_bug.cgi?id=80709 which converted an
existing
 JavaScript regions parsing test to use the W3C testharness.js in place
of
 js-test-pre.js/js-test-post.js.  This patch also places testharness.js
and a
 WebKit-specific testharnessreport.js file in
LayoutTests/fast/js/resources.


 Can we put them in LayoutTests/resources instead? I always find it hard
to
 remember the path fast/js/resources.

 In cases where tests need to be written for both the WebKit and W3C
 testing suites, having the ability to use testharness.js with WebKit
tests
 would mean that the test file only needs to be written once, and yet
can
 still rely on the functionality from both test harnesses.   As it
stands
 now, if someone needs to write a test for both suites, they either
have to
 implement all functionality from scratch, or write one version of the
test
 to use js-test-pre.js and another to use testharness.js.  The
inclusion of
 testharness.js in the WebKit repository alleviates the need for this
 duplication of effort.  The testharnessreport.js file was intended for
 customization of the capabilities provided by testharness.js, I've
added a
 call to layoutTestController.dumpAsText() to this file to allow it to
 function as a WebKit JavaScript test.


 I support the effort to make layout tests more compatible with W3C
tests.

 Is the plan to use testharness.js for all new tests? Or only tests that
we
 intend to contribute back to W3C?

 Another concern is that changes to testharness.js in the future that
break
 backward compatibility could then break WebKit tests.  This is an
issue I
 plan to discuss with W3C members to determine if backward
compatibility can
 be ensured.


 There is no such a guarantee at the moment? That concerns me. On other
hand,
 we wouldn't be importing ToT version of testharness.js so if such an
 incompatibility is introduced, we can migrate our tests on time as well.

 - Ryosuke


 ___
 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] Moving to Git?

2012-03-09 Thread Ashod Nakashian

- Original Message -

 From: Geoffrey Garen gga...@apple.com
 To: Ashod Nakashian ashodnakash...@yahoo.com
 Cc: David Barr davidb...@google.com; Ryosuke Niwa rn...@webkit.org; 
 WebKit Development webkit-dev@lists.webkit.org
 Sent: Saturday, March 10, 2012 2:58 AM
 Subject: Re: [webkit-dev] Moving to Git?

 I'm starting to see a mathematical relationship between
 (a) Volume of contribution to the WebKit OpenSource Project
 (b) Volume of advocacy for removing svn support from the WebKit OpenSource 
 Project

 The relationship seems to be of the inverse variety.

 In your case, Ashod:

 Source find . -name ChangeLog\* | xargs grep Nakashian | wc 
 -l
        2

I'm sorry if I don't see why this is a good argument. Is there a prerequisite 
for resurrecting a healthy discussion on a topic that is obviously of interest 
to many active contributes that I'm not aware of?

After all, what prompted me to raise this issue is because some svn scripts are 
outdated and before fixing them I thought may be there wasn't much use for them 
in the first place (otherwise, someone with a bigger contribution volume would 
certainly have noticed and fixed them sooner than me).

-Ash

 Geoff

 On Mar 9, 2012, at 7:14 AM, Ashod Nakashian wrote:

  I think if we address the main issues raised by the svn users, the current 
 consensus (if representative) seems to point towards an overwhelming support 
 (and demand?) for git over svn. On that point it's reasonable to say that 
 we're heading towards option #1 or #2 of Maciej. As such, I'm humbly 
 proposing the following (hopefully without getting ahead of myself):

  A) Address as many of the issues raised by the svn users and streamline 
 their use-cases in the current scripts on top of git that we can (this would 
 leave generation numbers out of scope as it's a git issue, although we can 
 push that on git's mail-list). Address any current issues that 
 (advanced/seasoned) git users find wanting/missing to have a solid system 
 that 
 capitalizes on the powers of git as much as possible.

  B) Plan a phase-out schedule for svn repo, servers and scripts and 
 mainlining git (this needs input from ops and those who can assess the 
 overhead 
 involved - something I'm ignorant of). Offer the option of having svn mirror 
 (however realistic that is, I can't tell) keeping in mind the overhead of 
 maintaining the svn scripts.

  If we don't do anything we'll be supporting both systems, scripts, 
 docs etc. with little advantage but having the choice of both systems 
 (status-quo). If we start moving towards git I think we'll end up with the 
 reverse situation than what we have now (git mainline, svn mirror) and, 
 assuming 
 the majority use git and there are more benefits to git over svn, then WebKit 
 will benefit more that way than the case is now. However, having said that, 
 something tells me the remaining svn users will probably switch to git sooner 
 rather than later.

  (Disclaimer: I enjoy svn as much as the next guy, but I think git offers 
 enough power to justify the overhead of learning/adapting/migrating to it. In 
 addition, as many pointed out, no one has to use all the power features and 
 the 
 svn-equivalent day-to-day ones can be automated transparently by current (and 
 new) scripts.)

  -Ash

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

Re: [webkit-dev] Moving to Git?

First, a follow up on my old post since my message was cut off in the
middle:
On Thu, Mar 8, 2012 at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason jma...@rim.com wrote:

 This is only slightly more complicated


 I'd say astoundingly more complicated because of


the fact that you're unapplying changes, updating the checkout, and
reapplying changes. This seemingly innocent sequence of operations have an
annoying side-effects of touching all files you've modified locally and
haven't committed.

So for example if you have any changes to Node.h and run this set of
operations, then git will touch Node.h twice by stashing and applying. This
would mean that I would be rebuilding the world even if all changes I get
from masters were in webkitpy or LayoutTests.

Are there an easy way to work around this issue as well? (other than
committing changes, of course)

On Fri, Mar 9, 2012 at 3:54 PM, Ashod Nakashian ashodnakash...@yahoo.comwrote:

 After all, what prompted me to raise this issue is because some svn
 scripts are outdated and before fixing them I thought may be there wasn't
 much use for them in the first place (otherwise, someone with a bigger
 contribution volume would certainly have noticed and fixed them sooner than
 me).


I suspect the only reason the particular bug hadn't been fixed is that we
have very few contributors who develop on Windows.

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

Re: [webkit-dev] Moving to Git?

2012-03-09 Thread David Levin

On Fri, Mar 9, 2012 at 4:01 PM, Ryosuke Niwa rn...@webkit.org wrote:


  git will touch Node.h twice by stashing and applying. This would mean
 that I would be rebuilding the world even if all changes I get from masters
 were in webkitpy or LayoutTests.

 Are there an easy way to work around this issue as well? (other than
 committing changes, of course)


afaik not really, here's two that I've used:

   1. git-new-workdir (multiple git working dirs so I don't switch branches
   as often)
   2. ccache (cache the results of the compile)

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

Re: [webkit-dev] Test conversion to use W3C testharness.js

Can we use some CSS tricks like :before to put the word PASS at the
beginning of the line for each subtest?

Adam


On Fri, Mar 9, 2012 at 3:51 PM, Jacob Goldstein jac...@adobe.com wrote:
 I replied to your comment in the bug, but will also copy below
 -

 I understand your concern.  Some of this is user defined, and the output
 could also be improved via customizations to the testharnessreport.js file.

 The message you see after Pass, for example, testParse: Assigned none
 to property, expected return = none, is the user defined string from the
 description argument of the assert_equals method.   assert_equals looks
 like this:

 assert_equals(actual, expected, description)

 All of the methods in testharness.js include a description argument that
 is output after the test result.  In the W3C test suite, the
 testharness.css file formats the output into a slightly more readable
 output.  Since we are dumping as text, that isn't possible, but other
 customizations in testharnessreport.js are.  I will look into this further.





 On 3/9/12 3:21 PM, Adam Barth aba...@webkit.org wrote:

I looked at the patch you uploaded, but it wasn't clear from the text
dump whether the subtests passed or failed.  Maybe testharness.js uses
a table and/or colors to present that information?  It's important
that we can easily determine which subtests pass or fail from a text
dump.

Adam


On Fri, Mar 9, 2012 at 3:19 PM, Jacob Goldstein jac...@adobe.com wrote:
 LayoutTests/resources is fine with me  that was the location I
considered
 using originally and only moved them to LayoutTests/fast/js/resources
 because that is where js-test-pre and post are.

 I'll upload a new patch with the files in LayoutTests/resources.



 From: Ryosuke Niwa rn...@webkit.org
 Date: Fri, 9 Mar 2012 14:37:18 -0800
 To: Jacob Goldstein jac...@adobe.com
 Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] Test conversion to use W3C testharness.js

 On Fri, Mar 9, 2012 at 2:28 PM, Jacob Goldstein jac...@adobe.com
wrote:

 I recently uploaded a patch
 to https://bugs.webkit.org/show_bug.cgi?id=80709 which converted an
existing
 JavaScript regions parsing test to use the W3C testharness.js in place
of
 js-test-pre.js/js-test-post.js.  This patch also places testharness.js
and a
 WebKit-specific testharnessreport.js file in
LayoutTests/fast/js/resources.


 Can we put them in LayoutTests/resources instead? I always find it hard
to
 remember the path fast/js/resources.

 In cases where tests need to be written for both the WebKit and W3C
 testing suites, having the ability to use testharness.js with WebKit
tests
 would mean that the test file only needs to be written once, and yet
can
 still rely on the functionality from both test harnesses.   As it
stands
 now, if someone needs to write a test for both suites, they either
have to
 implement all functionality from scratch, or write one version of the
test
 to use js-test-pre.js and another to use testharness.js.  The
inclusion of
 testharness.js in the WebKit repository alleviates the need for this
 duplication of effort.  The testharnessreport.js file was intended for
 customization of the capabilities provided by testharness.js, I've
added a
 call to layoutTestController.dumpAsText() to this file to allow it to
 function as a WebKit JavaScript test.


 I support the effort to make layout tests more compatible with W3C
tests.

 Is the plan to use testharness.js for all new tests? Or only tests that
we
 intend to contribute back to W3C?

 Another concern is that changes to testharness.js in the future that
break
 backward compatibility could then break WebKit tests.  This is an
issue I
 plan to discuss with W3C members to determine if backward
compatibility can
 be ensured.


 There is no such a guarantee at the moment? That concerns me. On other
hand,
 we wouldn't be importing ToT version of testharness.js so if such an
 incompatibility is introduced, we can migrate our tests on time as well.

 - Ryosuke


 ___
 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] Test conversion to use W3C testharness.js

Is your concern that the Pass is not in all caps?

The current output looks like this:

Result  Test Name   Message
PasstestParse: Assigned none to property, expected return = none


The pass at the beginning of the line is the test result.  Had the test
failed, this would read Fail.

The next portion of the line, in this case testParse: Assigned none to
property, expected return = none, is the description string specified in
the call to assert_equals.  The description can be any string that the
user specifies.

The spacing of the results when they are dumped as text obscures the
difference between the test result and description - this is something I
can address in a number of ways depending on everyone's preference.  I'll
investigate further and come up with some suggested fixes.





On 3/9/12 4:11 PM, Adam Barth aba...@webkit.org wrote:

Can we use some CSS tricks like :before to put the word PASS at the
beginning of the line for each subtest?

Adam


On Fri, Mar 9, 2012 at 3:51 PM, Jacob Goldstein jac...@adobe.com wrote:
 I replied to your comment in the bug, but will also copy below
 -

 I understand your concern.  Some of this is user defined, and the output
 could also be improved via customizations to the testharnessreport.js
file.

 The message you see after Pass, for example, testParse: Assigned none
 to property, expected return = none, is the user defined string from
the
 description argument of the assert_equals method.   assert_equals looks
 like this:

 assert_equals(actual, expected, description)

 All of the methods in testharness.js include a description argument that
 is output after the test result.  In the W3C test suite, the
 testharness.css file formats the output into a slightly more readable
 output.  Since we are dumping as text, that isn't possible, but other
 customizations in testharnessreport.js are.  I will look into this
further.





 On 3/9/12 3:21 PM, Adam Barth aba...@webkit.org wrote:

I looked at the patch you uploaded, but it wasn't clear from the text
dump whether the subtests passed or failed.  Maybe testharness.js uses
a table and/or colors to present that information?  It's important
that we can easily determine which subtests pass or fail from a text
dump.

Adam


On Fri, Mar 9, 2012 at 3:19 PM, Jacob Goldstein jac...@adobe.com
wrote:
 LayoutTests/resources is fine with me  that was the location I
considered
 using originally and only moved them to LayoutTests/fast/js/resources
 because that is where js-test-pre and post are.

 I'll upload a new patch with the files in LayoutTests/resources.



 From: Ryosuke Niwa rn...@webkit.org
 Date: Fri, 9 Mar 2012 14:37:18 -0800
 To: Jacob Goldstein jac...@adobe.com
 Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] Test conversion to use W3C testharness.js

 On Fri, Mar 9, 2012 at 2:28 PM, Jacob Goldstein jac...@adobe.com
wrote:

 I recently uploaded a patch
 to https://bugs.webkit.org/show_bug.cgi?id=80709 which converted an
existing
 JavaScript regions parsing test to use the W3C testharness.js in
place
of
 js-test-pre.js/js-test-post.js.  This patch also places
testharness.js
and a
 WebKit-specific testharnessreport.js file in
LayoutTests/fast/js/resources.


 Can we put them in LayoutTests/resources instead? I always find it
hard
to
 remember the path fast/js/resources.

 In cases where tests need to be written for both the WebKit and W3C
 testing suites, having the ability to use testharness.js with WebKit
tests
 would mean that the test file only needs to be written once, and yet
can
 still rely on the functionality from both test harnesses.   As it
stands
 now, if someone needs to write a test for both suites, they either
have to
 implement all functionality from scratch, or write one version of the
test
 to use js-test-pre.js and another to use testharness.js.  The
inclusion of
 testharness.js in the WebKit repository alleviates the need for this
 duplication of effort.  The testharnessreport.js file was intended
for
 customization of the capabilities provided by testharness.js, I've
added a
 call to layoutTestController.dumpAsText() to this file to allow it to
 function as a WebKit JavaScript test.


 I support the effort to make layout tests more compatible with W3C
tests.

 Is the plan to use testharness.js for all new tests? Or only tests
that
we
 intend to contribute back to W3C?

 Another concern is that changes to testharness.js in the future that
break
 backward compatibility could then break WebKit tests.  This is an
issue I
 plan to discuss with W3C members to determine if backward
compatibility can
 be ensured.


 There is no such a guarantee at the moment? That concerns me. On other
hand,
 we wouldn't be importing ToT version of testharness.js so if such an
 incompatibility is introduced, we can migrate our tests on time as
well.

 - Ryosuke


 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org

Re: [webkit-dev] Test conversion to use W3C testharness.js

Ah, I see now that the word Pass is there at the beginning of the
line.  I missed it because it ran together with the next couple words.
 Having spaces between the words would address my concern.

Thanks!
Adam


2012/3/9 Jacob Goldstein jac...@adobe.com:
 Is your concern that the Pass is not in all caps?

 The current output looks like this:

 Result  Test Name       Message
 Pass    testParse: Assigned none to property, expected return = none


 The pass at the beginning of the line is the test result.  Had the test
 failed, this would read Fail.

 The next portion of the line, in this case testParse: Assigned none to
 property, expected return = none, is the description string specified in
 the call to assert_equals.  The description can be any string that the
 user specifies.

 The spacing of the results when they are dumped as text obscures the
 difference between the test result and description - this is something I
 can address in a number of ways depending on everyone's preference.  I'll
 investigate further and come up with some suggested fixes.





 On 3/9/12 4:11 PM, Adam Barth aba...@webkit.org wrote:

Can we use some CSS tricks like :before to put the word PASS at the
beginning of the line for each subtest?

Adam


On Fri, Mar 9, 2012 at 3:51 PM, Jacob Goldstein jac...@adobe.com wrote:
 I replied to your comment in the bug, but will also copy below
 -

 I understand your concern.  Some of this is user defined, and the output
 could also be improved via customizations to the testharnessreport.js
file.

 The message you see after Pass, for example, testParse: Assigned none
 to property, expected return = none, is the user defined string from
the
 description argument of the assert_equals method.   assert_equals looks
 like this:

 assert_equals(actual, expected, description)

 All of the methods in testharness.js include a description argument that
 is output after the test result.  In the W3C test suite, the
 testharness.css file formats the output into a slightly more readable
 output.  Since we are dumping as text, that isn't possible, but other
 customizations in testharnessreport.js are.  I will look into this
further.





 On 3/9/12 3:21 PM, Adam Barth aba...@webkit.org wrote:

I looked at the patch you uploaded, but it wasn't clear from the text
dump whether the subtests passed or failed.  Maybe testharness.js uses
a table and/or colors to present that information?  It's important
that we can easily determine which subtests pass or fail from a text
dump.

Adam


On Fri, Mar 9, 2012 at 3:19 PM, Jacob Goldstein jac...@adobe.com
wrote:
 LayoutTests/resources is fine with me  that was the location I
considered
 using originally and only moved them to LayoutTests/fast/js/resources
 because that is where js-test-pre and post are.

 I'll upload a new patch with the files in LayoutTests/resources.



 From: Ryosuke Niwa rn...@webkit.org
 Date: Fri, 9 Mar 2012 14:37:18 -0800
 To: Jacob Goldstein jac...@adobe.com
 Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] Test conversion to use W3C testharness.js

 On Fri, Mar 9, 2012 at 2:28 PM, Jacob Goldstein jac...@adobe.com
wrote:

 I recently uploaded a patch
 to https://bugs.webkit.org/show_bug.cgi?id=80709 which converted an
existing
 JavaScript regions parsing test to use the W3C testharness.js in
place
of
 js-test-pre.js/js-test-post.js.  This patch also places
testharness.js
and a
 WebKit-specific testharnessreport.js file in
LayoutTests/fast/js/resources.


 Can we put them in LayoutTests/resources instead? I always find it
hard
to
 remember the path fast/js/resources.

 In cases where tests need to be written for both the WebKit and W3C
 testing suites, having the ability to use testharness.js with WebKit
tests
 would mean that the test file only needs to be written once, and yet
can
 still rely on the functionality from both test harnesses.   As it
stands
 now, if someone needs to write a test for both suites, they either
have to
 implement all functionality from scratch, or write one version of the
test
 to use js-test-pre.js and another to use testharness.js.  The
inclusion of
 testharness.js in the WebKit repository alleviates the need for this
 duplication of effort.  The testharnessreport.js file was intended
for
 customization of the capabilities provided by testharness.js, I've
added a
 call to layoutTestController.dumpAsText() to this file to allow it to
 function as a WebKit JavaScript test.


 I support the effort to make layout tests more compatible with W3C
tests.

 Is the plan to use testharness.js for all new tests? Or only tests
that
we
 intend to contribute back to W3C?

 Another concern is that changes to testharness.js in the future that
break
 backward compatibility could then break WebKit tests.  This is an
issue I
 plan to discuss with W3C members to determine if backward
compatibility can
 be ensured.


 There is no such a guarantee at the moment? That concerns me. On other

Re: [webkit-dev] Test conversion to use W3C testharness.js

Got it. I'll add more space after the Pass and see what other formatting makes 
sense and get back to you next week.



On Mar 9, 2012, at 5:15 PM, Adam Barth aba...@webkit.org wrote:

 Ah, I see now that the word Pass is there at the beginning of the
 line.  I missed it because it ran together with the next couple words.
 Having spaces between the words would address my concern.
 
 Thanks!
 Adam
 
 
 2012/3/9 Jacob Goldstein jac...@adobe.com:
 Is your concern that the Pass is not in all caps?
 
 The current output looks like this:
 
 Result  Test Name   Message
 PasstestParse: Assigned none to property, expected return = none
 
 
 The pass at the beginning of the line is the test result.  Had the test
 failed, this would read Fail.
 
 The next portion of the line, in this case testParse: Assigned none to
 property, expected return = none, is the description string specified in
 the call to assert_equals.  The description can be any string that the
 user specifies.
 
 The spacing of the results when they are dumped as text obscures the
 difference between the test result and description - this is something I
 can address in a number of ways depending on everyone's preference.  I'll
 investigate further and come up with some suggested fixes.
 
 
 
 
 
 On 3/9/12 4:11 PM, Adam Barth aba...@webkit.org wrote:
 
 Can we use some CSS tricks like :before to put the word PASS at the
 beginning of the line for each subtest?
 
 Adam
 
 
 On Fri, Mar 9, 2012 at 3:51 PM, Jacob Goldstein jac...@adobe.com wrote:
 I replied to your comment in the bug, but will also copy below
 -
 
 I understand your concern.  Some of this is user defined, and the output
 could also be improved via customizations to the testharnessreport.js
 file.
 
 The message you see after Pass, for example, testParse: Assigned none
 to property, expected return = none, is the user defined string from
 the
 description argument of the assert_equals method.   assert_equals looks
 like this:
 
 assert_equals(actual, expected, description)
 
 All of the methods in testharness.js include a description argument that
 is output after the test result.  In the W3C test suite, the
 testharness.css file formats the output into a slightly more readable
 output.  Since we are dumping as text, that isn't possible, but other
 customizations in testharnessreport.js are.  I will look into this
 further.
 
 
 
 
 
 On 3/9/12 3:21 PM, Adam Barth aba...@webkit.org wrote:
 
 I looked at the patch you uploaded, but it wasn't clear from the text
 dump whether the subtests passed or failed.  Maybe testharness.js uses
 a table and/or colors to present that information?  It's important
 that we can easily determine which subtests pass or fail from a text
 dump.
 
 Adam
 
 
 On Fri, Mar 9, 2012 at 3:19 PM, Jacob Goldstein jac...@adobe.com
 wrote:
 LayoutTests/resources is fine with me  that was the location I
 considered
 using originally and only moved them to LayoutTests/fast/js/resources
 because that is where js-test-pre and post are.
 
 I'll upload a new patch with the files in LayoutTests/resources.
 
 
 
 From: Ryosuke Niwa rn...@webkit.org
 Date: Fri, 9 Mar 2012 14:37:18 -0800
 To: Jacob Goldstein jac...@adobe.com
 Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] Test conversion to use W3C testharness.js
 
 On Fri, Mar 9, 2012 at 2:28 PM, Jacob Goldstein jac...@adobe.com
 wrote:
 
 I recently uploaded a patch
 to https://bugs.webkit.org/show_bug.cgi?id=80709 which converted an
 existing
 JavaScript regions parsing test to use the W3C testharness.js in
 place
 of
 js-test-pre.js/js-test-post.js.  This patch also places
 testharness.js
 and a
 WebKit-specific testharnessreport.js file in
 LayoutTests/fast/js/resources.
 
 
 Can we put them in LayoutTests/resources instead? I always find it
 hard
 to
 remember the path fast/js/resources.
 
 In cases where tests need to be written for both the WebKit and W3C
 testing suites, having the ability to use testharness.js with WebKit
 tests
 would mean that the test file only needs to be written once, and yet
 can
 still rely on the functionality from both test harnesses.   As it
 stands
 now, if someone needs to write a test for both suites, they either
 have to
 implement all functionality from scratch, or write one version of the
 test
 to use js-test-pre.js and another to use testharness.js.  The
 inclusion of
 testharness.js in the WebKit repository alleviates the need for this
 duplication of effort.  The testharnessreport.js file was intended
 for
 customization of the capabilities provided by testharness.js, I've
 added a
 call to layoutTestController.dumpAsText() to this file to allow it to
 function as a WebKit JavaScript test.
 
 
 I support the effort to make layout tests more compatible with W3C
 tests.
 
 Is the plan to use testharness.js for all new tests? Or only tests
 that
 we
 intend to contribute back to W3C?
 
 Another concern is that changes to

Re: [webkit-dev] Moving to Git?

On Mar 9, 2012 3:16 PM, Pablo Flouret pab...@motorola.com wrote:

 On Fri, 09 Mar 2012 14:47:17 -0800, Gustavo Noronha Silva g...@gnome.org
wrote:
 Tbh, I am much more interested in doing away with ChangeLogs than in
 feeling good about using git push instead of git svn dcommit. If we
 could find a way around ChangeLogs while keeping svn, then I would be an
 even happier panda than I am today =).

 +1

We can do this without moving to git. Here's how it might work:
1. When writing a patch, add a new temporary file e.g. ChangeLogEntry that
stores new change log entry in each directory where ChangeLogs are located.
2. ChangeLogEntry files are added to git/svn checkouts
3. Upload the patch (including ChangeLogEntry) for a review. Bugzilla shows
ChangeLogEntry filesas new files (can be tweeked,of course)
4. Once you get r+, you land the patch. The commit message editor will
automatically find ChangeLogEntry files and aggregate the result as the
commit message.
5. You commit. The commit hook ensures no ChangeLogEntry files are actually
committed into the svn repository.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Pablo Flouret


On Fri, 09 Mar 2012 17:55:59 -0800, Ryosuke Niwa rn...@webkit.org wrote:


On Mar 9, 2012 3:16 PM, Pablo Flouret pab...@motorola.com wrote:


On Fri, 09 Mar 2012 14:47:17 -0800, Gustavo Noronha Silva  
g...@gnome.org

wrote:

Tbh, I am much more interested in doing away with ChangeLogs than in
feeling good about using git push instead of git svn dcommit. If we
could find a way around ChangeLogs while keeping svn, then I would be  
an

even happier panda than I am today =).


+1


We can do this without moving to git. Here's how it might work:
1. When writing a patch, add a new temporary file e.g. ChangeLogEntry  
that
stores new change log entry in each directory where ChangeLogs are  
located.

2. ChangeLogEntry files are added to git/svn checkouts
3. Upload the patch (including ChangeLogEntry) for a review. Bugzilla  
shows

ChangeLogEntry filesas new files (can be tweeked,of course)
4. Once you get r+, you land the patch. The commit message editor will
automatically find ChangeLogEntry files and aggregate the result as the
commit message.
5. You commit. The commit hook ensures no ChangeLogEntry files are  
actually

committed into the svn repository.


That doesn't sound like much of an improvement.

I'd prefer to see something closer to what 'git format-patch' spits out.
Basically you give it a commit range and it spits out one diff per commit,  
including the commit message.


This gives a couple of interesting options, like having a single patch  
which can contain multiple commits. Or you can do some mangling like  
webkit-patch does today to take a commit-range diff and pretend that it's  
a single commit.
I imagine it shouldn't be too hard to replicate the format for someone  
using just svn.
A tool's UI for editing the commit message for svn users (or for the  
squash case) could somewhat mirror what the git rebase ui does for  
squashing. So you'd have a patch that includes commit messages ready for  
reviewers' perusal (which i presume is the biggest reason changelogs still  
exist?)


In my most frequent workflow i make a patch, submit it, make a local  
commit in git for myself (in a branch) and then move on to other things  
(in a different branch perhaps). Then when review comments come in, i  
address them, make a local commit with those changes, and upload a patch  
by giving a range to webkit-patch. ChangeLog files are a pain in the ass  
in this case. Also, reviewers don't get to see what changed between the  
two patches i uploaded, which a patch coming from format-patch would show.  
A final, squashed patch could be required for landing. Or both types could  
be submitted through webkit-patch and available in bugzilla. Or something  
else.


Anyway, just brainstorming a bit, haven't thought this through that much.

--
pablo flouret
motorola | webkit / browser team
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] The Gtk EWS bot is sick: no space left on device

2012-03-09 Thread Benjamin Poulain

Hello,

The Gtk EWS bot keep failing with:

Last 500 characters of output:
patch:  write error : No space left on device
patch:  write error : No space left on device
patch:  write error : No space left on device

Can anyone have a look at the poor machine?

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

[webkit-dev] Version control survey

2012-03-09 Thread Maciej Stachowiak


Since the answer to this factual question seems to be of interest to some 
people, here's a survey about what version control tools people use to access 
the WebKit repository, and approximate contribution level.

http://www.surveymonkey.com/s/JQMW2QV

(Note that it doesn't ask about preference for change, just what people use 
currently.)

Regards,
Maciej

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

Re: [webkit-dev] About BrowsingContext and WindowProxy spec

2012-03-09 Thread Sachin Puranik

Yes I second this thought. It aligns to general webkit terminology. I was
looking for a class with exact this name.

Regards,
Sachin.
On Mar 10, 2012 4:15 AM, Sam Weinig wei...@apple.com wrote:


 On Mar 7, 2012, at 9:25 PM, Darin Adler wrote:

  On Mar 7, 2012, at 9:34 AM, Adam Barth wrote:
 
  The WindowProxy is implemented in WebKit using the WindowShell class.
 
  Idle thought: We might want to consider renaming our WindowShell class
 WindowProxy, just to match the HTML specification concept, as I think we’ve
 done in a few other cases.
 
  -- Darin

 Yeah, we should do that.  Filed
 https://bugs.webkit.org/show_bug.cgi?id=80733.

 -Sam

 ___
 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] Version control survey

Can you add an option for folks who use both git and SVN?  I use both
frequently.

Thanks,
Adam


On Fri, Mar 9, 2012 at 10:20 PM, Maciej Stachowiak m...@apple.com wrote:

 Since the answer to this factual question seems to be of interest to some 
 people, here's a survey about what version control tools people use to access 
 the WebKit repository, and approximate contribution level.

 http://www.surveymonkey.com/s/JQMW2QV

 (Note that it doesn't ask about preference for change, just what people use 
 currently.)

 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

Re: [webkit-dev] The Gtk EWS bot is sick: no space left on device