Re: [webkit-dev] Deprecating JS interface
On Sat, Feb 16, 2013 at 11:26 PM, Dirk Schulze dschu...@adobe.com wrote: On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 16, 2013, at 10:16 PM, Dirk Schulze dschu...@adobe.com wrote: On Feb 16, 2013, at 6:54 PM, Adam Barth aba...@webkit.org 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
Re: [webkit-dev] Deprecating JS interface
On Feb 17, 2013, at 12:08 AM, Adam Barth aba...@webkit.org wrote: On Sat, Feb 16, 2013 at 11:26 PM, Dirk Schulze dschu...@adobe.com wrote: On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 16, 2013, at 10:16 PM, Dirk Schulze dschu...@adobe.com wrote: On Feb 16, 2013, at 6:54 PM, Adam Barth aba...@webkit.org 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 compiler flag ENABLE_DEPRECATED_FEATURES? This must be turned on in trunk to make sure deprecated features still work
Re: [webkit-dev] Deprecating JS interface
On Feb 17, 2013, at 1:04 AM, Dirk Schulze dschu...@adobe.com wrote: On Feb 17, 2013, at 12:08 AM, Adam Barth aba...@webkit.org wrote: On Sat, Feb 16, 2013 at 11:26 PM, Dirk Schulze dschu...@adobe.com wrote: On Feb 16, 2013, at 10:50 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 16, 2013, at 10:16 PM, Dirk Schulze dschu...@adobe.com wrote: On Feb 16, 2013, at 6:54 PM, Adam Barth aba...@webkit.org 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. 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?
Re: [webkit-dev] Deprecating JS interface
On Feb 17, 2013, at 1:09 AM, Filip Pizlo fpi...@apple.com wrote: On Feb 17, 2013, at 1:04 AM, Dirk Schulze dschu...@adobe.com 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
[webkit-dev] build.webkit.org problem
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] build.webkit.org problem
(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 mk...@google.com 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 o...@inf.u-szeged.hu 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-devhttps://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
On Feb 17, 2013, at 1:28 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 17, 2013, at 1:09 AM, Filip Pizlo fpi...@apple.com wrote: On Feb 17, 2013, at 1:04 AM, Dirk Schulze dschu...@adobe.com 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] Deprecating JS interface
On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze dschu...@adobe.com wrote: On Feb 17, 2013, at 1:28 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 17, 2013, at 1:09 AM, Filip Pizlo fpi...@apple.com wrote: On Feb 17, 2013, at 1:04 AM, Dirk Schulze dschu...@adobe.com 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] build.webkit.org problem
App engine error perhaps? http://webkit-commit-queue.appspot.com/active-bots On Sun, Feb 17, 2013 at 4:15 AM, Mike West mk...@chromium.org 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 mk...@google.com 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 o...@inf.u-szeged.hu 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
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 esei...@google.com wrote: App engine error perhaps? http://webkit-commit-queue.appspot.com/active-bots On Sun, Feb 17, 2013 at 4:15 AM, Mike West mk...@chromium.org 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 mk...@google.com 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 o...@inf.u-szeged.hu 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] sln files with wrong line endings
On 14/02/2013, at 6:23 pm, Vivek Galatage vivekgalat...@gmail.com 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 ch.du...@sisa.samsung.com 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=188263action=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] Deprecating JS interface
On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze dschu...@adobe.com 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] Deprecating JS interface
On Feb 17, 2013, at 2:47 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze dschu...@adobe.com 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
On Feb 17, 2013, at 3:02 PM, Dirk Schulze dschu...@adobe.com wrote: On Feb 17, 2013, at 9:16 AM, Adam Barth aba...@webkit.org wrote: On Sun, Feb 17, 2013 at 7:26 AM, Dirk Schulze dschu...@adobe.com 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 https://bugs.webkit.org/show_bug.cgi?id=108216 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] Version control survey results
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 m...@apple.com wrote: On Mar 22, 2012, at 9:16 PM, Adam Barth wrote: On Sat, Mar 10, 2012 at 12:49 PM, Maciej Stachowiak m...@apple.com 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
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 e...@webkit.org 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 m...@apple.com wrote: On Mar 22, 2012, at 9:16 PM, Adam Barth wrote: On Sat, Mar 10, 2012 at 12:49 PM, Maciej Stachowiak m...@apple.com 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
On Sun, Feb 17, 2013 at 9:54 PM, Maciej Stachowiak m...@apple.com 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 e...@webkit.org 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 m...@apple.com wrote: On Mar 22, 2012, at 9:16 PM, Adam Barth wrote: On Sat, Mar 10, 2012 at 12:49 PM, Maciej Stachowiak m...@apple.com 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
On Sun, Feb 17, 2013 at 10:07 PM, Eric Seidel e...@webkit.org wrote: On Sun, Feb 17, 2013 at 9:54 PM, Maciej Stachowiak m...@apple.com 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 e...@webkit.org 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 m...@apple.com wrote: On Mar 22, 2012, at 9:16 PM, Adam Barth wrote: On Sat, Mar 10, 2012 at 12:49 PM, Maciej Stachowiak m...@apple.com 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
On Sun, Feb 17, 2013 at 10:07 PM, Eric Seidel e...@webkit.org wrote: On Sun, Feb 17, 2013 at 9:54 PM, Maciej Stachowiak m...@apple.com 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
