Re: [webkit-dev] Version control survey results

[Ryosuke Niwa]

On Sun, Feb 17, 2013 at 10:07 PM, Eric Seidel  wrote:

> On Sun, Feb 17, 2013 at 9:54 PM, Maciej Stachowiak  wrote:
> >
> > There's probably proportionately more people using Git. Making these web
> surveys is a pain, so I'd rather not do it again if we don't need to.
> >
> > What would be the pros and cons of the master repository being git
> instead of svn, for git users?
>

As far as I could recall the last discussion, there won't be much benefit
in switching the master over to git unless we adopt git workflow (e.g.
first new links on https://www.google.com/search?q=git+workflow). In
particular, change loges are the biggest obstacle.

We could try to mitigate this divergence by allowing webkit-patch to fill
in change logs automatically from git commit messages when landing patches.
(I'm not volunteering to do this).

This involves commands like "webkit-patch upload" automatically pre
populating git commit messages (without modifying change logs) as they do
change logs today, and then commands like "webkit-patch land" automatically
parsing those git commit messages to populate change logs and commit
--amend them. Commands like "webkit patch apply-from-bug" can then parse
change log changes and convert them to git commit messages in turn.

I'm not sure how change logs should be updated/constructed in branch-merge
workflow.

But that's not really an argument I'm interested in pushing.  I
> believe eventually the remaining SVN users will switch to distributed
> version control of their own will, and we'll eventually decide to stop
> supporting SVN because not enough of the project is using it to
> justify causing the majority of users to use a translated solution.
>

FWIW, I don't plan to use git or any other distributed VCS in contributing
to WebKit. I like svn's simplicity.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Version control survey results

[Eric Seidel]

On Sun, Feb 17, 2013 at 10:07 PM, Eric Seidel  wrote:
> On Sun, Feb 17, 2013 at 9:54 PM, Maciej Stachowiak  wrote:
>>
>> There's probably proportionately more people using Git. Making these web 
>> surveys is a pain, so I'd rather not do it again if we don't need to.
>>
>> What would be the pros and cons of the master repository being git instead 
>> of svn, for git users?
>
> The conversion is clearly not loss-less. :)  So it's like asking what
> would be the pros of backing an SVN checkout with an SVN repository
> instead of a Git one (or a CVS one for that matter).

Of course I meant "backing an SVN checkout with a Git repository
instead of an SVN one (or a CVS one for that matter)."  If that makes
any more sense. :)

> I'm sure someone who cares more deeply about version control than I do
> could give you a list. :)
>
> But that's not really an argument I'm interested in pushing.  I
> believe eventually the remaining SVN users will switch to distributed
> version control of their own will, and we'll eventually decide to stop
> supporting SVN because not enough of the project is using it to
> justify causing the majority of users to use a translated solution.
>
> But we have larger problems to solve in WebKit besides what version
> control system we're using. :)
>
> I'm sorry for re-starting this thread and distracting from more
> important discussions.  It just crossed my mind for whatever reason
> again this evening.
>
>> (For current svn users I assume using svn would become effectively 
>> impossible; the only tool I could find to do this is server-side and 
>> essentially maintains git and svn repositories in parallel.)
>>
>>  - Maciej
>>
>> On Feb 17, 2013, at 9:00 PM, Eric Seidel  wrote:
>>
>>> I wonder if the git-taking-over-the-project trend has continued a year 
>>> later.
>>>
>>> I'm also glad to see efforts like
>>> https://bugs.webkit.org/show_bug.cgi?id=110073 towards standardizing
>>> on a simpler git workflow. :)
>>>
>>> Thanks again for running the survey.
>>>
>>> On Sat, Apr 7, 2012 at 4:58 PM, Maciej Stachowiak  wrote:

 On Mar 22, 2012, at 9:16 PM, Adam Barth wrote:

> On Sat, Mar 10, 2012 at 12:49 PM, Maciej Stachowiak  
> wrote:
>> I made a bad choice of survey site. They want to charge me to see more 
>> than
>> 100 responses or to export the data, but they won't take my money. 
>> Sadness.
>> Please try this survey instead, it will run through the 17th.
>
> The survey seems to be over.  Any word on the results?

 Here's the results:

 == All persons responding ==

 Total responses: 167
 Use SVN only: 24 (14%)
 Use SVN+ Git: 26 (16%)
 Use Git Only: 115 (69%)
 Other: 2 (1%)

 == Only committers + reviewers ==

 Total responses: 105
 Use SVN only: 18 (17%)
 Use SVN+ Git: 21 (20%)
 Use Git Only: 65 (62%)
 Other: 1 (1%)

 == Only reviewers ==

 Total responses: 48
 Use SVN only: 12 (25%)
 Use SVN+ Git: 13 (27%)
 Use Git Only: 22 (45%)
 Other: 1 (2%)

 == Values of "other" responses ==

 1 "git-svn"
 1 "Commit queue + trac"

 == Conclusions (assuming the sample is representative) ==

 - More of the WebKit community uses Git than SVN to access the WebKit 
 repository
 - Quite a few people use both
 - A significant proportion of the community uses SVN, and a significant 
 fraction of those use it exclusively
 - Reviewers (presumably longer-time, more experienced contributors) are 
 more likely to use SVN than newer contributors
 - Newer participants are particularly likely to use Git


 ___
 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
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Version control survey results

[Eric Seidel]

On Sun, Feb 17, 2013 at 9:54 PM, Maciej Stachowiak  wrote:
>
> There's probably proportionately more people using Git. Making these web 
> surveys is a pain, so I'd rather not do it again if we don't need to.
>
> What would be the pros and cons of the master repository being git instead of 
> svn, for git users?

The conversion is clearly not loss-less. :)  So it's like asking what
would be the pros of backing an SVN checkout with an SVN repository
instead of a Git one (or a CVS one for that matter).

I'm sure someone who cares more deeply about version control than I do
could give you a list. :)

But that's not really an argument I'm interested in pushing.  I
believe eventually the remaining SVN users will switch to distributed
version control of their own will, and we'll eventually decide to stop
supporting SVN because not enough of the project is using it to
justify causing the majority of users to use a translated solution.

But we have larger problems to solve in WebKit besides what version
control system we're using. :)

I'm sorry for re-starting this thread and distracting from more
important discussions.  It just crossed my mind for whatever reason
again this evening.

> (For current svn users I assume using svn would become effectively 
> impossible; the only tool I could find to do this is server-side and 
> essentially maintains git and svn repositories in parallel.)
>
>  - Maciej
>
> On Feb 17, 2013, at 9:00 PM, Eric Seidel  wrote:
>
>> I wonder if the git-taking-over-the-project trend has continued a year later.
>>
>> I'm also glad to see efforts like
>> https://bugs.webkit.org/show_bug.cgi?id=110073 towards standardizing
>> on a simpler git workflow. :)
>>
>> Thanks again for running the survey.
>>
>> On Sat, Apr 7, 2012 at 4:58 PM, Maciej Stachowiak  wrote:
>>>
>>> On Mar 22, 2012, at 9:16 PM, Adam Barth wrote:
>>>
 On Sat, Mar 10, 2012 at 12:49 PM, Maciej Stachowiak  wrote:
> I made a bad choice of survey site. They want to charge me to see more 
> than
> 100 responses or to export the data, but they won't take my money. 
> Sadness.
> Please try this survey instead, it will run through the 17th.

 The survey seems to be over.  Any word on the results?
>>>
>>> Here's the results:
>>>
>>> == All persons responding ==
>>>
>>> Total responses: 167
>>> Use SVN only: 24 (14%)
>>> Use SVN+ Git: 26 (16%)
>>> Use Git Only: 115 (69%)
>>> Other: 2 (1%)
>>>
>>> == Only committers + reviewers ==
>>>
>>> Total responses: 105
>>> Use SVN only: 18 (17%)
>>> Use SVN+ Git: 21 (20%)
>>> Use Git Only: 65 (62%)
>>> Other: 1 (1%)
>>>
>>> == Only reviewers ==
>>>
>>> Total responses: 48
>>> Use SVN only: 12 (25%)
>>> Use SVN+ Git: 13 (27%)
>>> Use Git Only: 22 (45%)
>>> Other: 1 (2%)
>>>
>>> == Values of "other" responses ==
>>>
>>> 1 "git-svn"
>>> 1 "Commit queue + trac"
>>>
>>> == Conclusions (assuming the sample is representative) ==
>>>
>>> - More of the WebKit community uses Git than SVN to access the WebKit 
>>> repository
>>> - Quite a few people use both
>>> - A significant proportion of the community uses SVN, and a significant 
>>> fraction of those use it exclusively
>>> - Reviewers (presumably longer-time, more experienced contributors) are 
>>> more likely to use SVN than newer contributors
>>> - Newer participants are particularly likely to use Git
>>>
>>>
>>> ___
>>> 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
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Version control survey results

[Maciej Stachowiak]

There's probably proportionately more people using Git. Making these web 
surveys is a pain, so I'd rather not do it again if we don't need to.

What would be the pros and cons of the master repository being git instead of 
svn, for git users? 

(For current svn users I assume using svn would become effectively impossible; 
the only tool I could find to do this is server-side and essentially maintains 
git and svn repositories in parallel.)

 - Maciej

On Feb 17, 2013, at 9:00 PM, Eric Seidel  wrote:

> I wonder if the git-taking-over-the-project trend has continued a year later.
> 
> I'm also glad to see efforts like
> https://bugs.webkit.org/show_bug.cgi?id=110073 towards standardizing
> on a simpler git workflow. :)
> 
> Thanks again for running the survey.
> 
> On Sat, Apr 7, 2012 at 4:58 PM, Maciej Stachowiak  wrote:
>> 
>> On Mar 22, 2012, at 9:16 PM, Adam Barth wrote:
>> 
>>> On Sat, Mar 10, 2012 at 12:49 PM, Maciej Stachowiak  wrote:
 I made a bad choice of survey site. They want to charge me to see more than
 100 responses or to export the data, but they won't take my money. Sadness.
 Please try this survey instead, it will run through the 17th.
>>> 
>>> The survey seems to be over.  Any word on the results?
>> 
>> Here's the results:
>> 
>> == All persons responding ==
>> 
>> Total responses: 167
>> Use SVN only: 24 (14%)
>> Use SVN+ Git: 26 (16%)
>> Use Git Only: 115 (69%)
>> Other: 2 (1%)
>> 
>> == Only committers + reviewers ==
>> 
>> Total responses: 105
>> Use SVN only: 18 (17%)
>> Use SVN+ Git: 21 (20%)
>> Use Git Only: 65 (62%)
>> Other: 1 (1%)
>> 
>> == Only reviewers ==
>> 
>> Total responses: 48
>> Use SVN only: 12 (25%)
>> Use SVN+ Git: 13 (27%)
>> Use Git Only: 22 (45%)
>> Other: 1 (2%)
>> 
>> == Values of "other" responses ==
>> 
>> 1 "git-svn"
>> 1 "Commit queue + trac"
>> 
>> == Conclusions (assuming the sample is representative) ==
>> 
>> - More of the WebKit community uses Git than SVN to access the WebKit 
>> repository
>> - Quite a few people use both
>> - A significant proportion of the community uses SVN, and a significant 
>> fraction of those use it exclusively
>> - Reviewers (presumably longer-time, more experienced contributors) are more 
>> likely to use SVN than newer contributors
>> - Newer participants are particularly likely to use Git
>> 
>> 
>> ___
>> 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
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Version control survey results

[Eric Seidel]

I wonder if the git-taking-over-the-project trend has continued a year later.

I'm also glad to see efforts like
https://bugs.webkit.org/show_bug.cgi?id=110073 towards standardizing
on a simpler git workflow. :)

Thanks again for running the survey.

On Sat, Apr 7, 2012 at 4:58 PM, Maciej Stachowiak  wrote:
>
> On Mar 22, 2012, at 9:16 PM, Adam Barth wrote:
>
>> On Sat, Mar 10, 2012 at 12:49 PM, Maciej Stachowiak  wrote:
>>> I made a bad choice of survey site. They want to charge me to see more than
>>> 100 responses or to export the data, but they won't take my money. Sadness.
>>> Please try this survey instead, it will run through the 17th.
>>
>> The survey seems to be over.  Any word on the results?
>
> Here's the results:
>
> == All persons responding ==
>
> Total responses: 167
> Use SVN only: 24 (14%)
> Use SVN+ Git: 26 (16%)
> Use Git Only: 115 (69%)
> Other: 2 (1%)
>
> == Only committers + reviewers ==
>
> Total responses: 105
> Use SVN only: 18 (17%)
> Use SVN+ Git: 21 (20%)
> Use Git Only: 65 (62%)
> Other: 1 (1%)
>
> == Only reviewers ==
>
> Total responses: 48
> Use SVN only: 12 (25%)
> Use SVN+ Git: 13 (27%)
> Use Git Only: 22 (45%)
> Other: 1 (2%)
>
> == Values of "other" responses ==
>
> 1 "git-svn"
> 1 "Commit queue + trac"
>
> == Conclusions (assuming the sample is representative) ==
>
> - More of the WebKit community uses Git than SVN to access the WebKit 
> repository
> - Quite a few people use both
> - A significant proportion of the community uses SVN, and a significant 
> fraction of those use it exclusively
> - Reviewers (presumably longer-time, more experienced contributors) are more 
> likely to use SVN than newer contributors
> - Newer participants are particularly likely to use Git
>
>
> ___
> 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
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deprecating JS interface

[Maciej Stachowiak]

On Feb 17, 2013, at 3:02 PM, Dirk Schulze  wrote:

> 
> On Feb 17, 2013, at 9:16 AM, Adam Barth  wrote:
> 
>> On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze  wrote:
>>> 
>>> Then we should face it. Prefixed content for CSS gradients, animation, 
>>> transition, transforms, CSS Image functions, masking and a lot more will 
>>> not go away. This basically means we will need to support them for an 
>>> undetermined period of time, possibly for the projects lifetime. This will 
>>> be the same for every popular prefixed feature that we introduce in the 
>>> future.
>>> 
>>> If we are honest about this we may can prevent future content to be a 
>>> burden on maintenance and use similar concepts as Mozilla does with runtime 
>>> flags on unprefixed features.
>> 
>> Just because we want to be thoughtful about which features we
>> deprecate doesn't mean that we'll be unsuccessful in removing
>> vendor-prefixed features.
> 
> I really hope so. Right now it looks like we hope that the time will solve 
> the problems that we introduced. I fear that this will not be the case for 
> some popular prefixed features and requires a bit more of a push. See the 
> 'mozOpacity' interface on Gecko[1] as one example. Otherwise we could end up 
> with the worst case scenario that less reviewers are capable to estimate the 
> influence of a patch.

We've successfully removed prefixed versions of features before. It will 
probably be harder for transitions and transforms than for some other things, 
but perhaps not impossible. The first step is getting to a point where we have 
a non-prefixed alternative, as  
does for transitions for instance.

Regards,
Maciej

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

Re: [webkit-dev] Deprecating JS interface

[Dirk Schulze]

On Feb 17, 2013, at 9:16 AM, Adam Barth  wrote:

> On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze  wrote:
>> On Feb 17, 2013, at 1:28 AM, Maciej Stachowiak  wrote:
>>> On Feb 17, 2013, at 1:09 AM, Filip Pizlo  wrote:
 On Feb 17, 2013, at 1:04 AM, Dirk Schulze  wrote:
> The discussion on each single feature let us forget the greater scope of 
> this problem. That is why I did not start with a concrete example.
> 
> What about going another direction? Right now we have compiler flags for 
> a lot of new features. What if we turn this around? Why not having a 
> compiler flag ENABLE_DEPRECATED_FEATURES? This must be turned on in trunk 
> to make sure deprecated features still work properly. Release builds 
> should turn it on to not break compatibility. But every binary build of a 
> nightly or preview has it turned off. A lot of developers experiment with 
> Chrome Canary and WebKit nightlies already. It might be a drop in the 
> bucket, but still can have some influence on decreasing the use of 
> deprecated content. Features like CSS gradients, transitions and 
> animations might be good candidates at the beginning for this flag.
 
 This carries the risk of decreasing test coverage of Nightlies and 
 Canaries.  I don't think that is acceptable.
 
 Users who download them and cannot use a web page because that page had 
 deprecated features will then not be able to experience what bugs we had, 
 those deprecated features notwithstanding.
 
 I empathize with the desire to remove cruft.  But we shouldn't remove 
 things if it breaks the web, even in Nightlies and Canaries.
>>> 
>>> I agree with Phil. And as a corollary, if removing something *doesn't* 
>>> break the Web and we think it's otherwise bad, then there's no need to do a 
>>> special dance with nightlies before removing.
>> 
>> Then we should face it. Prefixed content for CSS gradients, animation, 
>> transition, transforms, CSS Image functions, masking and a lot more will not 
>> go away. This basically means we will need to support them for an 
>> undetermined period of time, possibly for the projects lifetime. This will 
>> be the same for every popular prefixed feature that we introduce in the 
>> future.
>> 
>> If we are honest about this we may can prevent future content to be a burden 
>> on maintenance and use similar concepts as Mozilla does with runtime flags 
>> on unprefixed features.
> 
> Just because we want to be thoughtful about which features we
> deprecate doesn't mean that we'll be unsuccessful in removing
> vendor-prefixed features.

I really hope so. Right now it looks like we hope that the time will solve the 
problems that we introduced. I fear that this will not be the case for some 
popular prefixed features and requires a bit more of a push. See the 
'mozOpacity' interface on Gecko[1] as one example. Otherwise we could end up 
with the worst case scenario that less reviewers are capable to estimate the 
influence of a patch.

Greetings,
Dirk

[1]  https://bugzilla.mozilla.org/show_bug.cgi?id=765645

> 
> Adam

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

Re: [webkit-dev] Deprecating JS interface

[Dirk Schulze]

On Feb 17, 2013, at 2:47 PM, Ryosuke Niwa  wrote:

>> On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze  wrote:
>> Then we should face it. Prefixed content for CSS gradients, animation, 
>> transition, transforms, CSS Image functions, masking and a lot more will not 
>> go away. This basically means we will need to support them for an 
>> undetermined period of time, possibly for the projects lifetime. This will 
>> be the same for every popular prefixed feature that we introduce in the 
>> future.
>> 
>> If we are honest about this we may can prevent future content to be a burden 
>> on maintenance and use similar concepts as Mozilla does with runtime flags 
>> on unprefixed features.
> 
> This is why we need to be extremely careful when introducing new features. 

I absolutely agree.  Chrome introduced the runtime flags as one possible 
solution for this problem.

Greetings,
Dirk

> 
> - R. Niwa
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Deprecating JS interface

[Ryosuke Niwa]

On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze  wrote:

> Then we should face it. Prefixed content for CSS gradients, animation,
> transition, transforms, CSS Image functions, masking and a lot more will
> not go away. This basically means we will need to support them for an
> undetermined period of time, possibly for the projects lifetime. This will
> be the same for every popular prefixed feature that we introduce in the
> future.
>
> If we are honest about this we may can prevent future content to be a
> burden on maintenance and use similar concepts as Mozilla does with runtime
> flags on unprefixed features.
>

This is why we need to be extremely careful when introducing new features.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] sln files with wrong line endings

[Dean Jackson]

On 14/02/2013, at 6:23 pm, Vivek Galatage  wrote:

> I had the same problem and was able to trace the reason for this.
> 
> http://stackoverflow.com/questions/1889559/git-diff-to-ignore-m
> 
> Its the ^M characters at the EOL. git diff --ignore-space-at-eol ignores the 
> change from the diff.
> 
> Something similar was happening with 
> http://trac.webkit.org/browser/trunk/Source/WTF/WTF.vcproj/WTF.sln and its 
> changelog says it.

FWIW, I’ve hit something similar to this when rsyncing repositories between 
machines. All of a sudden, that WTF.sln file is marked as modified, but git 
diff can’t see the change.

I “fix" it by deleting the the .git/index and then doing a git checkout.

Dean

> 
> 
> 
> On Thu, Feb 14, 2013 at 12:40 PM, Christophe Dumez - SISA 
>  wrote:
> Hi,
> 
> The same thing has just happened to me. I managed to get rid of the changes 
> to this file by doing:
> git reset --hard
> 
> Kr,
> Christope Dumez.
> 
> From: webkit-dev-boun...@lists.webkit.org 
> [webkit-dev-boun...@lists.webkit.org] on behalf of Eric Seidel 
> [e...@webkit.org]
> Sent: Thursday, February 14, 2013 08:23
> To: WebKit Development
> Subject: [webkit-dev] sln files with wrong line endings
> 
> We've had this come up before, but I figure I should ask on webkit-dev
> to see if we have a solution. :)
> 
> Right now the Tools/DumpRenderTree/DumpRenderTree.vcxproj/DumpRenderTree.sln
> file is in some sort of bad state such that my Git checkout can't seem
> to not-modify the file.
> 
> I'm not sure if it's a Git bug, or a repository config bug.
> 
> But it means I can't seem to produce patches w/o modifying this file. :(
> 
> https://bugs.webkit.org/attachment.cgi?id=188263&action=review
> 
> Thoughts?
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] build.webkit.org problem

[Eric Seidel]

24.22.211.12 - - [17/Feb/2013:09:35:10 -0800] "GET /active-bots
HTTP/1.1" 500 0 "http://webkit-commit-queue.appspot.com/"; "Mozilla/5.0
(Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.17 (KHTML, like
Gecko) Chrome/24.0.1312.57 Safari/537.17"
"webkit-commit-queue.appspot.com" ms=9380 cpu_ms=2030
loading_request=1 pending_ms=1180 exit_code=105
instance=00c61b117ce3ad08e236a217d9ee5bdce8f5
C 2013-02-17 09:35:10.282
Exceeded soft private memory limit with 182.148 MB after servicing 0
requests total
I 2013-02-17 09:35:10.282
This request caused a new process to be started for your application,
and thus caused your application code to be loaded for the first time.
This request may thus take longer and use more CPU than a typical
request for your application.
W 2013-02-17 09:35:10.282
While handling this request, the process that handled this request was
found to be using too much memory and was terminated. This is likely
to cause a new process to be used for the next request to your
application. If you see this message frequently, you may have a memory
leak in your application.



On Sun, Feb 17, 2013 at 9:31 AM, Eric Seidel  wrote:
> App engine error perhaps?
>
> http://webkit-commit-queue.appspot.com/active-bots
>
>
> On Sun, Feb 17, 2013 at 4:15 AM, Mike West  wrote:
>> (Resending from the right address, sorry...)
>>
>> Perhaps relatedly (but probably not), the CQ and other Chromium EWS bots
>> apparently died about 13 hours ago: http://webkit-commit-queue.appspot.com/
>>
>> Adam, Eric, mind taking a quick look?
>>
>> -mike
>>
>>
>> -Mike
>>
>>
>> On Sun, Feb 17, 2013 at 12:29 PM, Mike West  wrote:
>>>
>>> Perhaps relatedly (but probably not), the CQ and other Chromium EWS bots
>>> apparently died about 13 hours ago: http://webkit-commit-queue.appspot.com/
>>>
>>> Adam, Eric, mind taking a quick look?
>>>
>>> -mike
>>>
>>> On Feb 17, 2013 10:30 AM, "Osztrogonác Csaba" 
>>> wrote:

 Hi,

 It seems something happened with build.webkit.org.
 There are pending builds on all builder, but the
 master doesn't make slaves start these builds.

 Could you check what happened with the buildbot master, please?

 Ossy
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] build.webkit.org problem

[Eric Seidel]

App engine error perhaps?

http://webkit-commit-queue.appspot.com/active-bots


On Sun, Feb 17, 2013 at 4:15 AM, Mike West  wrote:
> (Resending from the right address, sorry...)
>
> Perhaps relatedly (but probably not), the CQ and other Chromium EWS bots
> apparently died about 13 hours ago: http://webkit-commit-queue.appspot.com/
>
> Adam, Eric, mind taking a quick look?
>
> -mike
>
>
> -Mike
>
>
> On Sun, Feb 17, 2013 at 12:29 PM, Mike West  wrote:
>>
>> Perhaps relatedly (but probably not), the CQ and other Chromium EWS bots
>> apparently died about 13 hours ago: http://webkit-commit-queue.appspot.com/
>>
>> Adam, Eric, mind taking a quick look?
>>
>> -mike
>>
>> On Feb 17, 2013 10:30 AM, "Osztrogonác Csaba" 
>> wrote:
>>>
>>> Hi,
>>>
>>> It seems something happened with build.webkit.org.
>>> There are pending builds on all builder, but the
>>> master doesn't make slaves start these builds.
>>>
>>> Could you check what happened with the buildbot master, please?
>>>
>>> Ossy
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deprecating JS interface

[Adam Barth]

On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze  wrote:
> On Feb 17, 2013, at 1:28 AM, Maciej Stachowiak  wrote:
>> On Feb 17, 2013, at 1:09 AM, Filip Pizlo  wrote:
>>> On Feb 17, 2013, at 1:04 AM, Dirk Schulze  wrote:
 The discussion on each single feature let us forget the greater scope of 
 this problem. That is why I did not start with a concrete example.

 What about going another direction? Right now we have compiler flags for a 
 lot of new features. What if we turn this around? Why not having a 
 compiler flag ENABLE_DEPRECATED_FEATURES? This must be turned on in trunk 
 to make sure deprecated features still work properly. Release builds 
 should turn it on to not break compatibility. But every binary build of a 
 nightly or preview has it turned off. A lot of developers experiment with 
 Chrome Canary and WebKit nightlies already. It might be a drop in the 
 bucket, but still can have some influence on decreasing the use of 
 deprecated content. Features like CSS gradients, transitions and 
 animations might be good candidates at the beginning for this flag.
>>>
>>> This carries the risk of decreasing test coverage of Nightlies and 
>>> Canaries.  I don't think that is acceptable.
>>>
>>> Users who download them and cannot use a web page because that page had 
>>> deprecated features will then not be able to experience what bugs we had, 
>>> those deprecated features notwithstanding.
>>>
>>> I empathize with the desire to remove cruft.  But we shouldn't remove 
>>> things if it breaks the web, even in Nightlies and Canaries.
>>
>> I agree with Phil. And as a corollary, if removing something *doesn't* break 
>> the Web and we think it's otherwise bad, then there's no need to do a 
>> special dance with nightlies before removing.
>
> Then we should face it. Prefixed content for CSS gradients, animation, 
> transition, transforms, CSS Image functions, masking and a lot more will not 
> go away. This basically means we will need to support them for an 
> undetermined period of time, possibly for the projects lifetime. This will be 
> the same for every popular prefixed feature that we introduce in the future.
>
> If we are honest about this we may can prevent future content to be a burden 
> on maintenance and use similar concepts as Mozilla does with runtime flags on 
> unprefixed features.

Just because we want to be thoughtful about which features we
deprecate doesn't mean that we'll be unsuccessful in removing
vendor-prefixed features.

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

Re: [webkit-dev] Deprecating JS interface

[Dirk Schulze]

On Feb 17, 2013, at 1:28 AM, Maciej Stachowiak  wrote:

> 
> On Feb 17, 2013, at 1:09 AM, Filip Pizlo  wrote:
> 
>> 
>> On Feb 17, 2013, at 1:04 AM, Dirk Schulze  wrote:
>> 
>>> 
>>> The discussion on each single feature let us forget the greater scope of 
>>> this problem. That is why I did not start with a concrete example.
>>> 
>>> What about going another direction? Right now we have compiler flags for a 
>>> lot of new features. What if we turn this around? Why not having a compiler 
>>> flag ENABLE_DEPRECATED_FEATURES? This must be turned on in trunk to make 
>>> sure deprecated features still work properly. Release builds should turn it 
>>> on to not break compatibility. But every binary build of a nightly or 
>>> preview has it turned off. A lot of developers experiment with Chrome 
>>> Canary and WebKit nightlies already. It might be a drop in the bucket, but 
>>> still can have some influence on decreasing the use of deprecated content. 
>>> Features like CSS gradients, transitions and animations might be good 
>>> candidates at the beginning for this flag.
>> 
>> This carries the risk of decreasing test coverage of Nightlies and Canaries. 
>>  I don't think that is acceptable.
>> 
>> Users who download them and cannot use a web page because that page had 
>> deprecated features will then not be able to experience what bugs we had, 
>> those deprecated features notwithstanding.
>> 
>> I empathize with the desire to remove cruft.  But we shouldn't remove things 
>> if it breaks the web, even in Nightlies and Canaries.
> 
> I agree with Phil. And as a corollary, if removing something *doesn't* break 
> the Web and we think it's otherwise bad, then there's no need to do a special 
> dance with nightlies before removing.

Then we should face it. Prefixed content for CSS gradients, animation, 
transition, transforms, CSS Image functions, masking and a lot more will not go 
away. This basically means we will need to support them for an undetermined 
period of time, possibly for the projects lifetime. This will be the same for 
every popular prefixed feature that we introduce in the future.

If we are honest about this we may can prevent future content to be a burden on 
maintenance and use similar concepts as Mozilla does with runtime flags on 
unprefixed features.

Greetings,
Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] build.webkit.org problem

[Mike West]

(Resending from the right address, sorry...)

Perhaps relatedly (but probably not), the CQ and other Chromium EWS bots
apparently died about 13 hours ago: http://webkit-commit-queue.appspot.com/

Adam, Eric, mind taking a quick look?

-mike

-Mike


On Sun, Feb 17, 2013 at 12:29 PM, Mike West  wrote:

> Perhaps relatedly (but probably not), the CQ and other Chromium EWS bots
> apparently died about 13 hours ago:
> http://webkit-commit-queue.appspot.com/
>
> Adam, Eric, mind taking a quick look?
>
> -mike
> On Feb 17, 2013 10:30 AM, "Osztrogonác Csaba" 
> wrote:
>
>> Hi,
>>
>> It seems something happened with build.webkit.org.
>> There are pending builds on all builder, but the
>> master doesn't make slaves start these builds.
>>
>> Could you check what happened with the buildbot master, please?
>>
>> Ossy
>> __**_
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/**mailman/listinfo/webkit-dev
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] How to get patch test at different platform before webkit-patch upload

[徐征]

Hi, Benjamin

Thank you so much for advice and review.
You are right that we can not expect different platform to render as 
same pixel images.


I have modified source code based on comment.
And modified TestExpectations(add line such as following) for chromium, 
gtk, win and qt.


# Needs rebaseline because platform-specific
webkit.org/b/78957 fast/text/decorations-with-ruby-underline-expand.html 
[ Failure ]


Thank you again and looking forward review result.

BR,
Zheng

(2013/02/17 11:07), Benjamin Poulain wrote:

Hi,

On Sat, Feb 16, 2013 at 5:45 PM, 徐征 > wrote:


I am handling this issue
(https://bugs.webkit.org/show_bug.cgi?id=78957)
now.
My question is I test my added test code locally, however, it seems
failed on some other platform(get red on cr-linux).
So can I(and how can I) test my added test code on some EWS before I
upload some patch?


The cr-linux bot is the only EWS running the pixel tests. Your test 
likely fails on everything but Mac.


The problem is you assume the pixel test will be the same on all 
platform. Because the way fonts are rendered varies, the resulting 
images vary with each platform.


In those cases, you can generate results for the platform you are 
working on, and mark the test for rebaseline in the "TestExpectations" 
files of the other platforms (in 
LayoutTest/platform/platformFooBar/TestExpectations).


Cheers,
Benjamin


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

[webkit-dev] build.webkit.org problem

[Osztrogonác Csaba]

Hi,

It seems something happened with build.webkit.org.
There are pending builds on all builder, but the
master doesn't make slaves start these builds.

Could you check what happened with the buildbot master, please?

Ossy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deprecating JS interface

[Maciej Stachowiak]

On Feb 17, 2013, at 1:09 AM, Filip Pizlo  wrote:

> 
> On Feb 17, 2013, at 1:04 AM, Dirk Schulze  wrote:
> 
>> 
>> The discussion on each single feature let us forget the greater scope of 
>> this problem. That is why I did not start with a concrete example.
>> 
>> What about going another direction? Right now we have compiler flags for a 
>> lot of new features. What if we turn this around? Why not having a compiler 
>> flag ENABLE_DEPRECATED_FEATURES? This must be turned on in trunk to make 
>> sure deprecated features still work properly. Release builds should turn it 
>> on to not break compatibility. But every binary build of a nightly or 
>> preview has it turned off. A lot of developers experiment with Chrome Canary 
>> and WebKit nightlies already. It might be a drop in the bucket, but still 
>> can have some influence on decreasing the use of deprecated content. 
>> Features like CSS gradients, transitions and animations might be good 
>> candidates at the beginning for this flag.
> 
> This carries the risk of decreasing test coverage of Nightlies and Canaries.  
> I don't think that is acceptable.
> 
> Users who download them and cannot use a web page because that page had 
> deprecated features will then not be able to experience what bugs we had, 
> those deprecated features notwithstanding.
> 
> I empathize with the desire to remove cruft.  But we shouldn't remove things 
> if it breaks the web, even in Nightlies and Canaries.

I agree with Phil. And as a corollary, if removing something *doesn't* break 
the Web and we think it's otherwise bad, then there's no need to do a special 
dance with nightlies before removing.

Cheers,
Maciej

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

Re: [webkit-dev] Deprecating JS interface

[Filip Pizlo]

On Feb 17, 2013, at 1:04 AM, Dirk Schulze  wrote:

> 
> On Feb 17, 2013, at 12:08 AM, Adam Barth  wrote:
> 
>> On Sat, Feb 16, 2013 at 11:26 PM, Dirk Schulze  wrote:
>>> On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak  wrote:
 On Feb 16, 2013, at 10:16 PM, Dirk Schulze  wrote:
> On Feb 16, 2013, at 6:54 PM, Adam Barth  wrote:
> 
>> It's much easier to discuss a concrete example.  Which interface are
>> you interested in deprecating?
> 
> I can understand that it is easier to discuss on a concrete example, even 
> if I would like to discuss this in a general scope. We have multiple 
> interfaces that we may want to deprecate at some point.
> 
> A concrete example I thought about is WebKitCSSMatrix[1]. It is not used 
> in WebCore yet but hopefully replaced by a standardized Matrix interface 
> in the future[2]. This new interface will not be fully compatible to 
> WebKitCSSMatrix and I would like to warn authors before they actually 
> start using it.
 
 Since you're the one designing the new interface (or at least you are the 
 spec editor), why don't you just make it compatible? Breaking changes to 
 existing Web APIs should only be done as a last resort, and I don't 
 understand the justification for doing it here.
>>> 
>>> It is a proposal so far and no draft yet. Technically, I am not the editor 
>>> of it so. The proposal has quite some way to go (hopefully not too much) 
>>> and I do not plan to land anything in this direction as long as the 
>>> responsible WGs did not agree on continuing with the proposal and the 
>>> general direction. I will post a separate mail with the actual feature 
>>> implementation announcement when the time comes.
>>> 
 Then we have a much simper transition story, and WebKitCSSMatrix can be 
 aliased to the new class.
>>> 
>>> I indeed tried to preserve the behavior of WebKitCSSMatrix as much as 
>>> possible. I got an action of the SVG WG to work on a replacement for 
>>> SVGMatrix. The highest priority was to preserver the behavior of SVGMatrix 
>>> (which is definitely actively used by web content) and provide a basic 
>>> interface that can be used beyond just SVG. There are a lot of use cases in 
>>> the near future for a generalized matrix IMO. SVG, CSS Transforms, Canvas 
>>> and WebGL are the obvious once. A specification interoperable format to 
>>> share transformation data seems extremely desirable. I encourage everyone 
>>> who is interested to look at the proposal and give feedback.
>>> 
 
> 
> Again, I think it would be better to discuss this in a wider scope but am 
> happy to discuss it on the concrete example as well. This actually might 
> make it easier to come up with general rules in the future.
 
 I think spamming the console is not a useful thing to do for interfaces 
 that actually have significant usage in the wild. A more productive step 
 would be to measure usage of WebKitCSSMatrix. If it's reasonably high, 
 we're not going to be able to remove it.
>>> 
>>> I agree that we need more metrics to discuss the next active steps on 
>>> WebKitCSSMatrix and I already uploaded a patch to add it to the 
>>> FeatureObserver[1].
>>> 
>>> The question remains: How do we want to continue with deprecating WebKit 
>>> specific features in the long term. Especially when we have a standard 
>>> compliant replacement. It is extremely hard to maintain all different 
>>> behaviors. So far we have multiple implementations of background, flex-box, 
>>> gradients to name some. This doesn't scale very well and there will be a 
>>> time where we can not guarantee for the correct functioning of old 
>>> features. This is a problem that other browsers like IE are focused for 
>>> quite some time as well (not necessarily successfully). As long as we are 
>>> concerned to deprecate and remove features, we increase the complexity of 
>>> the code base. Less and less reviewers will be able to determine the 
>>> behavior of patches to the general code base, while we increase the feature 
>>> count and interoperability between modules more and more. There is no other 
>>> way then to risk breaking content that relies on non-standardized behavior 
>>> of platforms. And we should formalize th
 i
> s
>> to give a bit more reliability to web authors. The last section on [2] is 
>> too vague at the moment.
>> 
>> I don't think we're be successful at formalizing a general approach at
>> this time.  Instead, we should consider each case in turn and use our
>> best judgement.  If a pattern emerges over time, we might want to
>> document that pattern in
>> http://trac.webkit.org/wiki/DeprecatingFeatures.
>> 
>> At the moment, deprecating WebKitCSSMatrix seems premature as there
>> isn't yet a suitable replacement.
> 
> The discussion on each single feature let us forget the greater scope of this 
> problem. That is why I did not start with a concrete example

Re: [webkit-dev] Deprecating JS interface

[Dirk Schulze]

On Feb 17, 2013, at 12:08 AM, Adam Barth  wrote:

> On Sat, Feb 16, 2013 at 11:26 PM, Dirk Schulze  wrote:
>> On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak  wrote:
>>> On Feb 16, 2013, at 10:16 PM, Dirk Schulze  wrote:
 On Feb 16, 2013, at 6:54 PM, Adam Barth  wrote:
 
> It's much easier to discuss a concrete example.  Which interface are
> you interested in deprecating?
 
 I can understand that it is easier to discuss on a concrete example, even 
 if I would like to discuss this in a general scope. We have multiple 
 interfaces that we may want to deprecate at some point.
 
 A concrete example I thought about is WebKitCSSMatrix[1]. It is not used 
 in WebCore yet but hopefully replaced by a standardized Matrix interface 
 in the future[2]. This new interface will not be fully compatible to 
 WebKitCSSMatrix and I would like to warn authors before they actually 
 start using it.
>>> 
>>> Since you're the one designing the new interface (or at least you are the 
>>> spec editor), why don't you just make it compatible? Breaking changes to 
>>> existing Web APIs should only be done as a last resort, and I don't 
>>> understand the justification for doing it here.
>> 
>> It is a proposal so far and no draft yet. Technically, I am not the editor 
>> of it so. The proposal has quite some way to go (hopefully not too much) and 
>> I do not plan to land anything in this direction as long as the responsible 
>> WGs did not agree on continuing with the proposal and the general direction. 
>> I will post a separate mail with the actual feature implementation 
>> announcement when the time comes.
>> 
>>> Then we have a much simper transition story, and WebKitCSSMatrix can be 
>>> aliased to the new class.
>> 
>> I indeed tried to preserve the behavior of WebKitCSSMatrix as much as 
>> possible. I got an action of the SVG WG to work on a replacement for 
>> SVGMatrix. The highest priority was to preserver the behavior of SVGMatrix 
>> (which is definitely actively used by web content) and provide a basic 
>> interface that can be used beyond just SVG. There are a lot of use cases in 
>> the near future for a generalized matrix IMO. SVG, CSS Transforms, Canvas 
>> and WebGL are the obvious once. A specification interoperable format to 
>> share transformation data seems extremely desirable. I encourage everyone 
>> who is interested to look at the proposal and give feedback.
>> 
>>> 
 
 Again, I think it would be better to discuss this in a wider scope but am 
 happy to discuss it on the concrete example as well. This actually might 
 make it easier to come up with general rules in the future.
>>> 
>>> I think spamming the console is not a useful thing to do for interfaces 
>>> that actually have significant usage in the wild. A more productive step 
>>> would be to measure usage of WebKitCSSMatrix. If it's reasonably high, 
>>> we're not going to be able to remove it.
>> 
>> I agree that we need more metrics to discuss the next active steps on 
>> WebKitCSSMatrix and I already uploaded a patch to add it to the 
>> FeatureObserver[1].
>> 
>> The question remains: How do we want to continue with deprecating WebKit 
>> specific features in the long term. Especially when we have a standard 
>> compliant replacement. It is extremely hard to maintain all different 
>> behaviors. So far we have multiple implementations of background, flex-box, 
>> gradients to name some. This doesn't scale very well and there will be a 
>> time where we can not guarantee for the correct functioning of old features. 
>> This is a problem that other browsers like IE are focused for quite some 
>> time as well (not necessarily successfully). As long as we are concerned to 
>> deprecate and remove features, we increase the complexity of the code base. 
>> Less and less reviewers will be able to determine the behavior of patches to 
>> the general code base, while we increase the feature count and 
>> interoperability between modules more and more. There is no other way then 
>> to risk breaking content that relies on non-standardized behavior of 
>> platforms. And we should formalize thi
 s
>  to give a bit more reliability to web authors. The last section on [2] is 
> too vague at the moment.
> 
> I don't think we're be successful at formalizing a general approach at
> this time.  Instead, we should consider each case in turn and use our
> best judgement.  If a pattern emerges over time, we might want to
> document that pattern in
> http://trac.webkit.org/wiki/DeprecatingFeatures.
> 
> At the moment, deprecating WebKitCSSMatrix seems premature as there
> isn't yet a suitable replacement.

The discussion on each single feature let us forget the greater scope of this 
problem. That is why I did not start with a concrete example.

What about going another direction? Right now we have compiler flags for a lot 
of new features. What if we turn this around? Why not having a com

Re: [webkit-dev] Deprecating JS interface

[Adam Barth]

On Sat, Feb 16, 2013 at 11:26 PM, Dirk Schulze  wrote:
> On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak  wrote:
>> On Feb 16, 2013, at 10:16 PM, Dirk Schulze  wrote:
>>> On Feb 16, 2013, at 6:54 PM, Adam Barth  wrote:
>>>
 It's much easier to discuss a concrete example.  Which interface are
 you interested in deprecating?
>>>
>>> I can understand that it is easier to discuss on a concrete example, even 
>>> if I would like to discuss this in a general scope. We have multiple 
>>> interfaces that we may want to deprecate at some point.
>>>
>>> A concrete example I thought about is WebKitCSSMatrix[1]. It is not used in 
>>> WebCore yet but hopefully replaced by a standardized Matrix interface in 
>>> the future[2]. This new interface will not be fully compatible to 
>>> WebKitCSSMatrix and I would like to warn authors before they actually start 
>>> using it.
>>
>> Since you're the one designing the new interface (or at least you are the 
>> spec editor), why don't you just make it compatible? Breaking changes to 
>> existing Web APIs should only be done as a last resort, and I don't 
>> understand the justification for doing it here.
>
> It is a proposal so far and no draft yet. Technically, I am not the editor of 
> it so. The proposal has quite some way to go (hopefully not too much) and I 
> do not plan to land anything in this direction as long as the responsible WGs 
> did not agree on continuing with the proposal and the general direction. I 
> will post a separate mail with the actual feature implementation announcement 
> when the time comes.
>
>> Then we have a much simper transition story, and WebKitCSSMatrix can be 
>> aliased to the new class.
>
> I indeed tried to preserve the behavior of WebKitCSSMatrix as much as 
> possible. I got an action of the SVG WG to work on a replacement for 
> SVGMatrix. The highest priority was to preserver the behavior of SVGMatrix 
> (which is definitely actively used by web content) and provide a basic 
> interface that can be used beyond just SVG. There are a lot of use cases in 
> the near future for a generalized matrix IMO. SVG, CSS Transforms, Canvas and 
> WebGL are the obvious once. A specification interoperable format to share 
> transformation data seems extremely desirable. I encourage everyone who is 
> interested to look at the proposal and give feedback.
>
>>
>>>
>>> Again, I think it would be better to discuss this in a wider scope but am 
>>> happy to discuss it on the concrete example as well. This actually might 
>>> make it easier to come up with general rules in the future.
>>
>> I think spamming the console is not a useful thing to do for interfaces that 
>> actually have significant usage in the wild. A more productive step would be 
>> to measure usage of WebKitCSSMatrix. If it's reasonably high, we're not 
>> going to be able to remove it.
>
> I agree that we need more metrics to discuss the next active steps on 
> WebKitCSSMatrix and I already uploaded a patch to add it to the 
> FeatureObserver[1].
>
> The question remains: How do we want to continue with deprecating WebKit 
> specific features in the long term. Especially when we have a standard 
> compliant replacement. It is extremely hard to maintain all different 
> behaviors. So far we have multiple implementations of background, flex-box, 
> gradients to name some. This doesn't scale very well and there will be a time 
> where we can not guarantee for the correct functioning of old features. This 
> is a problem that other browsers like IE are focused for quite some time as 
> well (not necessarily successfully). As long as we are concerned to deprecate 
> and remove features, we increase the complexity of the code base. Less and 
> less reviewers will be able to determine the behavior of patches to the 
> general code base, while we increase the feature count and interoperability 
> between modules more and more. There is no other way then to risk breaking 
> content that relies on non-standardized behavior of platforms. And we should 
> formalize this
  to give a bit more reliability to web authors. The last section on [2] is too 
vague at the moment.

I don't think we're be successful at formalizing a general approach at
this time.  Instead, we should consider each case in turn and use our
best judgement.  If a pattern emerges over time, we might want to
document that pattern in
http://trac.webkit.org/wiki/DeprecatingFeatures.

At the moment, deprecating WebKitCSSMatrix seems premature as there
isn't yet a suitable replacement.

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