Re: [webkit-dev] Deleting V8 bindings (was Cleaning House)
On 04/04/2013 09:14 PM, Ryosuke Niwa wrote: On the other hand, I don't think optimizing WebCore for JSC doesn't necessarily mean it'll become impossible for you to have a custom build of WebKit that uses some other binding code. For example, Mac has Objective-C bindings and that's not going anywhere in the foreseeable future. True, but Objective-C bindings are *in addition* to JSC. Our use of Nashorn *replaces* JSC. Still, we can certainly have local changes in the code-base, like we currently do. My worry is about the places the code hard-wires in an assumption on JSC - if those proliferate it will complicate us keeping updated with WebKit. I can see the logic for simplifying, and I'm not asking you to support an alternative JavaScript engine where it complicates the code. Just please keep in mind there are people who use WebKit *without* JSC. -- --Per Bothner per.both...@oracle.com p...@bothner.com http://per.bothner.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Sunsetting committership and reviewership
Hi, This is somewhat related to the bulk move of Chromium-WebKit contributors to Blink, but we might want to consider sunsetting/expiring committership and reviewership. I'm thinking of something like expiring committership/reviwership of a person after the person didn't have any SVN activities for 3 or 6 months. Any thoughts or opinions? - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Hi, The Qt port of WebKit (based on Qt 5.x) does not use v8. (Qt 5.x uses v8 in other places, but that is not relevant to the WebKit project and this discussion) Simon Markus kamika...@gmx.de wrote: For the record though I don't think Qt is using any of that those. Qt 5.x uses V8. ___ 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] Sunsetting committership and reviewership
I am not sure this is really needed. People sometimes disappear from working on trunk for extended periods of time due to internal products and downstream branches. It has happened multiple times to me. That doesn't mean that I won't come back and start working upstream later. Also it could be that some people working on Blink would like to contribute to WebKit in their spare time or in the future again. Part of being a reviewer is also knowing what and when to review, so I am not sure there really is an issue here. Cheers Kenneth On Fri, Apr 5, 2013 at 8:19 AM, Ryosuke Niwa rn...@webkit.org wrote: Hi, This is somewhat related to the bulk move of Chromium-WebKit contributors to Blink, but we might want to consider sunsetting/expiring committership and reviewership. I'm thinking of something like expiring committership/reviwership of a person after the person didn't have any SVN activities for 3 or 6 months. Any thoughts or opinions? - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4294 9458 / E-mail kenneth at webkit.org ﹆﹆﹆ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Sunsetting committership and reviewership
On Apr 5, 2013, at 2:19 AM, Ryosuke Niwa rn...@webkit.org wrote: Hi, This is somewhat related to the bulk move of Chromium-WebKit contributors to Blink, but we might want to consider sunsetting/expiring committership and reviewership. I'm thinking of something like expiring committership/reviwership of a person after the person didn't have any SVN activities for 3 or 6 months. Any thoughts or opinions? My third-party perspective: This might make sense for reviewer status which is more about project leadership/direction but perhaps not for committer status which is more about proven good judgement and experience. I don't think the WebKit code base evolves so unexpectedly that 6 months invalidates the qualifications for committer status. Also consider: 1. Removing committers is actually more work than not removing them -- you now need to track start dates and run jobs to identify expired people. You also potentially need warnings, a review process in case of mistakes, etc. 2. People employed for WebKit development might be absent 6 months for totally valid reasons like maternity/paternity leave. Regards, Marshall - 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] Sunsetting committership and reviewership
Am 05.04.2013 um 08:19 schrieb Ryosuke Niwa rn...@webkit.org: Hi, This is somewhat related to the bulk move of Chromium-WebKit contributors to Blink, but we might want to consider sunsetting/expiring committership and reviewership. I'm thinking of something like expiring committership/reviwership of a person after the person didn't have any SVN activities for 3 or 6 months. Hm, that sounds really harsh - at least if the person is still within the WebKit project. I personally couldn't land a patch the last months as I'm busy with my thesis, but I'm clearly still qualified for SVG reviews and discussions, no? I follow development closely, even if not writing patches on my own at the moment. Cheers, Niko ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Sunsetting committership and reviewership
On Apr 4, 2013, at 11:19 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, This is somewhat related to the bulk move of Chromium-WebKit contributors to Blink, but we might want to consider sunsetting/expiring committership and reviewership. I'm thinking of something like expiring committership/reviwership of a person after the person didn't have any SVN activities for 3 or 6 months. Any thoughts or opinions? This seems reactionary. We never had an activity counter before. Actually, I know WebKit reviewers who stopped working on the project for 2 years and restarted the activity later. Even with a fast growing community and an always changing code base, the expertise was still good enough to continue where stopped right away. On the controversy, it may leave people at the Blink project who want to switch back to WebKit later and even more harm is done to the WebKit project. I object to such a proposal. 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] Sunsetting committership and reviewership
On Thu, Apr 4, 2013 at 11:53 PM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: I am not sure this is really needed. People sometimes disappear from working on trunk for extended periods of time due to internal products and downstream branches. It has happened multiple times to me. That doesn't mean that I won't come back and start working upstream later. Also it could be that some people working on Blink would like to contribute to WebKit in their spare time or in the future again. Part of being a reviewer is also knowing what and when to review, so I am not sure there really is an issue here. I'm not too concerned about the reviwership but more about committership from a security point of view. I don't think a lot of committers are going to monitor their old SVN accounts and update passwords periodically. Having lots of inactive SVN accounts isn't that helpful. Maybe I didn't phrase it correctly, but I'm suggesting more of suspension so that we have a smaller attack surface for SVN credentials. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Sunsetting committership and reviewership
On Thu, Apr 4, 2013 at 11:56 PM, Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de wrote: Am 05.04.2013 um 08:19 schrieb Ryosuke Niwa rn...@webkit.org: Hi, This is somewhat related to the bulk move of Chromium-WebKit contributors to Blink, but we might want to consider sunsetting/expiring committership and reviewership. I'm thinking of something like expiring committership/reviwership of a person after the person didn't have any SVN activities for 3 or 6 months. Hm, that sounds really harsh - at least if the person is still within the WebKit project. I personally couldn't land a patch the last months as I'm busy with my thesis, but I'm clearly still qualified for SVG reviews and discussions, no? I follow development closely, even if not writing patches on my own at the moment. Would something like one year be a reasonable timeframe? I'm not suggesting that you have to go through non-committer status and wait for committer/reviewer nominations again once you passed that threshold. It's more about temporarily suspending accounts and removing people from committers.py to better access control things. If they're coming back to WebKit, they can request their committerships and reviewerships reinstated. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Sunsetting committership and reviewership
Neither here nor there, but... I had interest in sunsetting committers/reviewers in the past. There are loads of folks listed in committers.py who haven't committed or reviewed in 5+ years. I believe there are some old threads on webkit-reviewers about such. I believe the timeout for sunsetting discussed in those old threads was more along the lines of 2-years. I should note that committers.py has some historical uses (for associating committers with commits), so you might want to consider using an emeritus section instead of removing entries. Best of luck. On Fri, Apr 5, 2013 at 12:05 AM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Apr 4, 2013 at 11:56 PM, Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de wrote: Am 05.04.2013 um 08:19 schrieb Ryosuke Niwa rn...@webkit.org: Hi, This is somewhat related to the bulk move of Chromium-WebKit contributors to Blink, but we might want to consider sunsetting/expiring committership and reviewership. I'm thinking of something like expiring committership/reviwership of a person after the person didn't have any SVN activities for 3 or 6 months. Hm, that sounds really harsh - at least if the person is still within the WebKit project. I personally couldn't land a patch the last months as I'm busy with my thesis, but I'm clearly still qualified for SVG reviews and discussions, no? I follow development closely, even if not writing patches on my own at the moment. Would something like one year be a reasonable timeframe? I'm not suggesting that you have to go through non-committer status and wait for committer/reviewer nominations again once you passed that threshold. It's more about temporarily suspending accounts and removing people from committers.py to better access control things. If they're coming back to WebKit, they can request their committerships and reviewerships reinstated. - 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] Sunsetting committership and reviewership
Sorry. Wrong address again. On Fri, Apr 5, 2013 at 12:09 AM, Eric Seidel esei...@google.com wrote: Neither here nor there, but... I had interest in sunsetting committers/reviewers in the past. There are loads of folks listed in committers.py who haven't committed or reviewed in 5+ years. I believe there are some old threads on webkit-reviewers about such. I believe the timeout for sunsetting discussed in those old threads was more along the lines of 2-years. I should note that committers.py has some historical uses (for associating committers with commits), so you might want to consider using an emeritus section instead of removing entries. Best of luck. On Fri, Apr 5, 2013 at 12:05 AM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Apr 4, 2013 at 11:56 PM, Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de wrote: Am 05.04.2013 um 08:19 schrieb Ryosuke Niwa rn...@webkit.org: Hi, This is somewhat related to the bulk move of Chromium-WebKit contributors to Blink, but we might want to consider sunsetting/expiring committership and reviewership. I'm thinking of something like expiring committership/reviwership of a person after the person didn't have any SVN activities for 3 or 6 months. Hm, that sounds really harsh - at least if the person is still within the WebKit project. I personally couldn't land a patch the last months as I'm busy with my thesis, but I'm clearly still qualified for SVG reviews and discussions, no? I follow development closely, even if not writing patches on my own at the moment. Would something like one year be a reasonable timeframe? I'm not suggesting that you have to go through non-committer status and wait for committer/reviewer nominations again once you passed that threshold. It's more about temporarily suspending accounts and removing people from committers.py to better access control things. If they're coming back to WebKit, they can request their committerships and reviewerships reinstated. - 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] Sunsetting committership and reviewership
Sent from my iPhone On Apr 5, 2013, at 12:00 AM, Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org wrote: On Thu, Apr 4, 2013 at 11:53 PM, Kenneth Rohde Christiansen kenneth.christian...@gmail.commailto:kenneth.christian...@gmail.com wrote: I am not sure this is really needed. People sometimes disappear from working on trunk for extended periods of time due to internal products and downstream branches. It has happened multiple times to me. That doesn't mean that I won't come back and start working upstream later. Also it could be that some people working on Blink would like to contribute to WebKit in their spare time or in the future again. Part of being a reviewer is also knowing what and when to review, so I am not sure there really is an issue here. I'm not too concerned about the reviwership but more about committership from a security point of view. I don't think a lot of committers are going to monitor their old SVN accounts and update passwords periodically. Having lots of inactive SVN accounts isn't that helpful. Maybe I didn't phrase it correctly, but I'm suggesting more of suspension so that we have a smaller attack surface for SVN credentials. Suggesting the deactivation of the SVN account is reasonable, as long as you get it back on request. Greetings Dirk - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto: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] Sunsetting committership and reviewership
On Apr 4, 2013, at 11:19 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, This is somewhat related to the bulk move of Chromium-WebKit contributors to Blink, but we might want to consider sunsetting/expiring committership and reviewership. I'm thinking of something like expiring committership/reviwership of a person after the person didn't have any SVN activities for 3 or 6 months. Any thoughts or opinions? Not a completely unreasonable idea, but I feel 3-6 months is way too short. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Sunsetting committership and reviewership
On Fri, Apr 5, 2013 at 12:21 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 4, 2013, at 11:19 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, This is somewhat related to the bulk move of Chromium-WebKit contributors to Blink, but we might want to consider sunsetting/expiring committership and reviewership. I'm thinking of something like expiring committership/reviwership of a person after the person didn't have any SVN activities for 3 or 6 months. Any thoughts or opinions? Not a completely unreasonable idea, but I feel 3-6 months is way too short. How about 2 years as Eric cited? - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Status of Windows Port?
Hi, On Fri, Apr 5, 2013 at 12:19 AM, Benjamin Poulain benja...@webkit.orgwrote: I don't know exactly what is the problem with integrating Qt...but I think fixing that will be far less work than making a new WebKit2 port from scratch. WebKitGTK+ also run on Windows. But I don't know if it supports WebKit2. No, WebKit2GTK+ is not supported on Windows. If someone is willing to do the work we might consider adding it, but it's not in our plans at the moment. Of course as you mention WebKitGTK+ (WebKit1) is supported on Windows. Xan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Hi Geoff, First of all, let me say upfront that I see all the potential advantages of sticking to just one JS engine, and also perfectly understand the points that most of the people here have made on favour of not supporting multiple engines. Also, my mail was not really a formal request to keep the V8 bits around in the long term, but just a quick reply to the following comment from Maciej: Geoff posted the list in part because we'd like to know If any of the things above are used by other ports. We're not planning to remove things still in use. So, my position with regard to this is pretty much the same as Per's one, so I'll just quote him too: I'm not asking you to support an alternative JavaScript engine where it complicates the code. Just please keep in mind there are people who use WebKit *without* JSC. Now I will try to answer your questions... [...] Who do you envision maintaining the v8 bindings going forward? In an ideal world, I would see the people interested in using those bindings doing it. And as per the feedback received so far, I understand it's just us for the V8 bindings, and maybe Oracle for the more generic bits about supporting multiple JS engines. However, that depends on whether those who were interested in WebKit + !JSC keep their interest on that for the long term, and I don't think this is a question that can be answered right now, as it probably depends on some other decisions. What do you see as their value to the WebKit project? I'm not an expert on JS engines at all, so I just see the obvious short term benefit of not breaking right now WebKit+V8 configurations that might be in use, and a more long-term benefit of having the needed bits in place to support other JS engines different than V8. Now, whether those are good enough benefits to keep this part of the code around in the future or not is something I can't answer either. Do you see any cost to the WebKit project in maintaining the v8 bindings? Yes. I obviously see the cost and limitations imposed by having to maintain code to support more than one JS engine when, in most of the cases, only one (JSC) will be used. Also, considering that JSC will be the only one supported in WebKit2 suggests that whoever who try to use WebKit with other engine is going to have a hard time maintaining downstream patches that will probably be harder and harder to deal with over time. So yes, I'm not blind on this topic. I clearly see the drawbacks :) Does the benefit outweigh the cost? As I said, I'm not an expert on the matter, but after reading the comments here, I feel like benefit probably won't outweight the cost in the long run. What would it take for WebKitGTK+ to adopt the JSC bindings? Martin already kindly answered this. To finish this mail, I'd just like to stress again that I was not requesting to keep this code forever in my previous mail. My point was more about keeping those bits for a while, or that just giving a smaller priority to the removal, since that would probably be appreciated in the short term by those that are currently using engines other than JSC. Thanks, Mario ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Qui, 2013-04-04 at 18:46 +0200, Balazs Kelemen wrote: FWIW, mrobinson has been working on a GYP build for the GTK port, so I wouldn't delete all of the .gyp files (at least not w/o them weighing in on it). I thought there was some interest at Apple in also using GYP, but perhaps things have (or will) change given that interop w/ Chromium is no longer the big plus it would've been. We discussed this briefly yesterday and we seem to have a consensus there's no point in going further with that plan, since there's nobody else showing interest right now (if we're wrong let us know!). We will try to adopt cmake instead. Do you mean adopting cmake for the whole project, or just for Gtk? I mean the GTK+ port only, sorry for the confusion. When I said 'We' I meant Martin Robinson and myself. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Also, WebP project is unfinished state right now. This changeset requires libwebp version 0.3.0: https://trac.webkit.org/changeset/147048 But version 0.3.0 also supports animated webp, and google doesn't have the code for animation support in WEBPImageDecoder.cpp yet, not even in Chromium. So this needs to be maintained somehow. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Hi Mario. First of all, let me say upfront that I see all the potential advantages of sticking to just one JS engine, and also perfectly understand the points that most of the people here have made on favour of not supporting multiple engines. Also, my mail was not really a formal request to keep the V8 bits around in the long term, but just a quick reply to the following comment from Maciej: Geoff posted the list in part because we'd like to know If any of the things above are used by other ports. We're not planning to remove things still in use. So, my position with regard to this is pretty much the same as Per's one, so I'll just quote him too: I'm not asking you to support an alternative JavaScript engine where it complicates the code. Just please keep in mind there are people who use WebKit *without* JSC. Thanks for clarifying. It sounds like you're not asking us to maintain the v8 bindings. Who do you envision maintaining the v8 bindings going forward? In an ideal world, I would see the people interested in using those bindings doing it. And as per the feedback received so far, I understand it's just us for the V8 bindings, and maybe Oracle for the more generic bits about supporting multiple JS engines. However, that depends on whether those who were interested in WebKit + !JSC keep their interest on that for the long term, and I don't think this is a question that can be answered right now, as it probably depends on some other decisions. I apologize if this question was a little to Socratic. The point of the question was to identify real world challenges and solutions, not an ideal world. My understanding is that, in the real world, nobody is maintaining the v8 bindings. As of today, there are no v8 ports in WebKit trunk that build successfully. What do you see as their value to the WebKit project? I'm not an expert on JS engines at all, so I just see the obvious short term benefit of not breaking right now WebKit+V8 configurations that might be in use, and a more long-term benefit of having the needed bits in place to support other JS engines different than V8. Now, whether those are good enough benefits to keep this part of the code around in the future or not is something I can't answer either. Do you see any cost to the WebKit project in maintaining the v8 bindings? Yes. I obviously see the cost and limitations imposed by having to maintain code to support more than one JS engine when, in most of the cases, only one (JSC) will be used. Also, considering that JSC will be the only one supported in WebKit2 suggests that whoever who try to use WebKit with other engine is going to have a hard time maintaining downstream patches that will probably be harder and harder to deal with over time. So yes, I'm not blind on this topic. I clearly see the drawbacks :) Does the benefit outweigh the cost? As I said, I'm not an expert on the matter, but after reading the comments here, I feel like benefit probably won't outweight the cost in the long run. What would it take for WebKitGTK+ to adopt the JSC bindings? Martin already kindly answered this. To finish this mail, I'd just like to stress again that I was not requesting to keep this code forever in my previous mail. My point was more about keeping those bits for a while, or that just giving a smaller priority to the removal, since that would probably be appreciated in the short term by those that are currently using engines other than JSC. I'm not clear on what you're proposing here. How long should we wait to remove the v8 bindings? The uses of the v8 bindings I've heard of -- Oracle's Java project, a GTK project, and a Qt project -- are downstream adopters that don't work in WebKit trunk, and that can adjust to this change at their leisure. Since I haven't heard of a specific disruption that will happen to a WebKit trunk contributor, I'm planning to remove the v8 bindings today. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Friday 05 April 2013, Max Stepin wrote: Also, WebP project is unfinished state right now. This changeset requires libwebp version 0.3.0: https://trac.webkit.org/changeset/147048 To me it looks more like it requires 0.3.0 to enable color correction. Older ABIs are still supported. `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
To me it looks more like it requires 0.3.0 to enable color correction. Older ABIs are still supported. Yes, but some WebP images (created with 0.3.0) will not work. I tried, not even the first frame is displayed. Would it be OK to just take future WEBPImageDecoder.cpp updates from Chromium? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deleting V8 bindings (was Cleaning House)
There are plenty of other bindings - Gtk has a set of dom bindings i believe, there used to be COM (shudder) bindings as well, but those aren't the problem. We could have as many binding languages as we want, there's no major architectural reason not to. But supporting javascript isn't simply a matter of another binding. The complexity comes from javascript being the internal scripting language used by webcore for script tags, etc. It's that complexity that creates the need for massive abstraction when supporting multiple distinct JS engines. There is simply no way to support multiple JS engines without retaining the current abstraction - the fact that it's currently only present in order to support the existence of V8 isn't relevant - the same machinery would be necessary to support _any_ other JS engine in addition to JSC. There is strictly no advantage to WebKit in keeping that machinery, it is purely performance and opportunity cost. You need an _extremely_ compelling argument to outweigh those costs. --Oliver On Apr 4, 2013, at 11:15 PM, Per Bothner per.both...@oracle.com wrote: On 04/04/2013 09:14 PM, Ryosuke Niwa wrote: On the other hand, I don't think optimizing WebCore for JSC doesn't necessarily mean it'll become impossible for you to have a custom build of WebKit that uses some other binding code. For example, Mac has Objective-C bindings and that's not going anywhere in the foreseeable future. True, but Objective-C bindings are *in addition* to JSC. Our use of Nashorn *replaces* JSC. Still, we can certainly have local changes in the code-base, like we currently do. My worry is about the places the code hard-wires in an assumption on JSC - if those proliferate it will complicate us keeping updated with WebKit. I can see the logic for simplifying, and I'm not asking you to support an alternative JavaScript engine where it complicates the code. Just please keep in mind there are people who use WebKit *without* JSC. -- --Per Bothner per.both...@oracle.com p...@bothner.com http://per.bothner.com/ ___ 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] Cleaning House
On Friday 05 April 2013, Max Stepin wrote: To me it looks more like it requires 0.3.0 to enable color correction. Older ABIs are still supported. Yes, but some WebP images (created with 0.3.0) will not work. I tried, not even the first frame is displayed. Would it be OK to just take future WEBPImageDecoder.cpp updates from Chromium? I would guess that is the plan for all cross-engine relevant fixes as long as the internal APIs remain similar enough. `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Apr 5, 2013, at 5:25 AM, Mario Sanchez Prada mario.pr...@samsung.com wrote: Also, my mail was not really a formal request to keep the V8 bits around in the long term, but just a quick reply to the following comment from Maciej: Geoff posted the list in part because we'd like to know If any of the things above are used by other ports. We're not planning to remove things still in use. So, my position with regard to this is pretty much the same as Per's one, so I'll just quote him too: I'm not asking you to support an alternative JavaScript engine where it complicates the code. Just please keep in mind there are people who use WebKit *without* JSC. By in-use I meant by in-tree ports. I don't think it makes sense to keep functionality in trunk that is only used by out-of-tree ports, if it is costly to do so. The maintainers of the separate tree can make the effort to support extra functionality in their own branch. After all, if you have a private tree, you can make whatever changes you want in your own repository. It's not entirely fair to ask upstream to do that maintenance work for you. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Friday, April 05, 2013 09:24:59 AM Geoffrey Garen wrote: Hi Mario. First of all, let me say upfront that I see all the potential advantages of sticking to just one JS engine, and also perfectly understand the points that most of the people here have made on favour of not supporting multiple engines. Also, my mail was not really a formal request to keep the V8 bits around in the long term, but just a quick reply to the following comment from Maciej: Geoff posted the list in part because we'd like to know If any of the things above are used by other ports. We're not planning to remove things still in use. So, my position with regard to this is pretty much the same as Per's one, so I'll just quote him too: I'm not asking you to support an alternative JavaScript engine where it complicates the code. Just please keep in mind there are people who use WebKit *without* JSC. Thanks for clarifying. It sounds like you're not asking us to maintain the v8 bindings. Who do you envision maintaining the v8 bindings going forward? In an ideal world, I would see the people interested in using those bindings doing it. And as per the feedback received so far, I understand it's just us for the V8 bindings, and maybe Oracle for the more generic bits about supporting multiple JS engines. However, that depends on whether those who were interested in WebKit + !JSC keep their interest on that for the long term, and I don't think this is a question that can be answered right now, as it probably depends on some other decisions. I apologize if this question was a little to Socratic. The point of the question was to identify real world challenges and solutions, not an ideal world. My understanding is that, in the real world, nobody is maintaining the v8 bindings. As of today, there are no v8 ports in WebKit trunk that build successfully. What do you see as their value to the WebKit project? I'm not an expert on JS engines at all, so I just see the obvious short term benefit of not breaking right now WebKit+V8 configurations that might be in use, and a more long-term benefit of having the needed bits in place to support other JS engines different than V8. Now, whether those are good enough benefits to keep this part of the code around in the future or not is something I can't answer either. Do you see any cost to the WebKit project in maintaining the v8 bindings? Yes. I obviously see the cost and limitations imposed by having to maintain code to support more than one JS engine when, in most of the cases, only one (JSC) will be used. Also, considering that JSC will be the only one supported in WebKit2 suggests that whoever who try to use WebKit with other engine is going to have a hard time maintaining downstream patches that will probably be harder and harder to deal with over time. So yes, I'm not blind on this topic. I clearly see the drawbacks :) Does the benefit outweigh the cost? As I said, I'm not an expert on the matter, but after reading the comments here, I feel like benefit probably won't outweight the cost in the long run. What would it take for WebKitGTK+ to adopt the JSC bindings? Martin already kindly answered this. To finish this mail, I'd just like to stress again that I was not requesting to keep this code forever in my previous mail. My point was more about keeping those bits for a while, or that just giving a smaller priority to the removal, since that would probably be appreciated in the short term by those that are currently using engines other than JSC. I'm not clear on what you're proposing here. How long should we wait to remove the v8 bindings? The uses of the v8 bindings I've heard of -- Oracle's Java project, a GTK project, and a Qt project -- are downstream adopters that don't work in WebKit trunk, and that can adjust to this change at their leisure. Qt doesn't use it at all, Oracle use just the structure used to support multiple JS engines (that will probably vanish after v8 removal), not the v8 bindings. Since I haven't heard of a specific disruption that will happen to a WebKit trunk contributor, I'm planning to remove the v8 bindings today. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev signature.asc Description: This is a digitally signed message part. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Apple is taking over the commit queue
On Thu, Apr 4, 2013 at 9:18 PM, Ryosuke Niwa rn...@webkit.org wrote: I've temporarily disabled testing on the commit queue in http://trac.webkit.org/changeset/147695 since we haven't added enough hardwares to keep up with patches. I'll re-enable testing once we've got up to speed. Again, thanks for your cooperation and patience. Lucas and I added two more machines so we have three machines in the total for the commit queue. I'll re-enable testing on the commit queue now. Let me know if commit-queue gets stuck or not processing your patch. Also, we've started running our own style queue and feeder queue instances. I'm also preparing to run our own sheriffbot instance. Thank you all (especially Adam, Eric, Dirk) for helping us make this transition. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
