Re: [webkit-dev] Breaking other ports
On Tue, Jan 29, 2013 at 11:58 PM, Maciej Stachowiak m...@apple.com wrote: I agree that the regression should be fixed. But before we discuss that... I am puzzled by the apparent stance of Alexey must immediately fix this himself or we must revert immediately. That's not the standard we have applied in the past to changes that appear generally correct but end up breaking the UI of a client of a specific port. No one said Alexey must immediately fix this himself or we must revert immediately. Here's what I said: If you cannot address the issue immediately, please let me know so that I can take further action. Further actions might include me fixing the issue myself. I hadn't figured that out yet. I just needed an answer quickly so that I could make sure we resolved this issue in the appropriate time frame. To me this example seems pretty parallel to the situation https://bugs.webkit.org/show_bug.cgi?id=108214. Can anyone explain to me why 108214 is being approached so much more aggressively than 52988. Honestly, it's because you've changed the ground rules for contributing to WebKit such that it's now ok to break other ports in some situations. When Alexey wrote: The fact that you chose to do an obvious hack instead does not make it others' responsibility to support it. I interpreted that to mean he felt justified in extending those ground rules to parts of WebCore that don't live up to his personal engineering standards. I wanted to be clear that I view that as unacceptable. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: Custom Elements
Hi Maciej, Thanks for your attention! For reference: will the feature flag be comprehensive, or will parts of the implementation/scaffolding be outside the ifdef? It should be comprehensive. So it will. Although some trivial inline stubs, like just returning null or false, or even doing nothing, will be outside the flag for minimizing if/def disturbance, they'll be optimized out by compilers. Also, some kind of refactoring might precede to make new features fit in the code. Such refactoring will be aimed to achieve clear separation of new additions by, for example, introducing better encapsulation. (Please note that this is just a general direction of the change. I have no concrete refactoring plan in my mind at this time.) As an example, here is the first bit of the change: https://bugs.webkit.org/attachment.cgi?id=185411action=review I expect most of the code from this feature to grow under these CustomElementSomething and accompany classes. Hope this answers your question. -- morrita On Wed, Jan 30, 2013 at 4:52 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 29, 2013, at 6:22 PM, Hajime Morrita morr...@chromium.org wrote: Hi folks, I'm going to implement Custom Elements standard behind ENABLE(CUSTOM_ELEMENTS) flag. https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html For reference: will the feature flag be comprehensive, or will parts of the implementation/scaffolding be outside the ifdef? - Maciej Here is the tracking bug for the feature: https://bugs.webkit.org/show_bug.cgi?id=99688 Note that Mozilla is also working on implementing this. https://bugzilla.mozilla.org/show_bug.cgi?id=783129 Let me know if you have any questions or comments. Bests, -- morrita ___ 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] Breaking other ports
On Jan 30, 2013, at 12:21 AM, Adam Barth aba...@webkit.org wrote: On Tue, Jan 29, 2013 at 11:58 PM, Maciej Stachowiak m...@apple.com wrote: I agree that the regression should be fixed. But before we discuss that... I am puzzled by the apparent stance of Alexey must immediately fix this himself or we must revert immediately. That's not the standard we have applied in the past to changes that appear generally correct but end up breaking the UI of a client of a specific port. No one said Alexey must immediately fix this himself or we must revert immediately. In the email I was replying to, James said If Alexey doesn't want to look into the regression, which is valid, then the only clear option is to roll it out until someone who is familiar with the breakage can look at it If Alexey is interested in learning about this and fixing it, that's fine, but in the meantime the regression can't be left in the tree. I think my paraphrase is reasonable. If it's not what James meant, I welcome clarification. Here's what I said: If you cannot address the issue immediately, please let me know so that I can take further action. Further actions might include me fixing the issue myself. I hadn't figured that out yet. I just needed an answer quickly so that I could make sure we resolved this issue in the appropriate time frame. This is probably stating the obvious, but you can't support a no one said assertion with a single example of something you said. Though I was mainly replying to James, you also said: I filed bug 108214 about the regression. Please either fix the regression or roll out your change. https://bugs.webkit.org/show_bug.cgi?id=106147#c12 In fact, this was posted at almost the same time as your other comment, and likely colored perceptions of what you meant by further action. So though I wasn't replying to you, I think it would have been reasonable to infer a similar position. If that's not what you meant, then that's good news, but I think you could have communicated your intent more clearly. To me this example seems pretty parallel to the situation https://bugs.webkit.org/show_bug.cgi?id=108214. Can anyone explain to me why 108214 is being approached so much more aggressively than 52988. Honestly, it's because you've changed the ground rules for contributing to WebKit such that it's now ok to break other ports in some situations. When Alexey wrote: The fact that you chose to do an obvious hack instead does not make it others' responsibility to support it. Your comment that I cited above seems pretty aggressive to me, and was prior to Alexey's comment that you quoted. I think what Alexey said was needlessly inflammatory, but it was in response to your needlessly inflammatory remark rather than the cause of it. So it seems to me that the suddenly more aggressive stance on this type of regression did not originate with Alexey's remark, unless you have a time machine. I interpreted that to mean he felt justified in extending those ground rules to parts of WebCore that don't live up to his personal engineering standards. I wanted to be clear that I view that as unacceptable. Your interpretation seems like quite a stretch. Particularly since we've had an in-person conversation about Apple's plans to apply an owners file to WebKit2, where the plans were explained in some detail, including mentioning that we had no intent whatsoever to apply any such policy to WebCore. Arguing with your own extrapolated version of someone else's position is likely to be perceived a strawman argument. It's not a good thing to do if you want to have a good faith discussion. If you actually were sincerely confused about the scope of the policy (which I'm somewhat skeptical of, but willing to grant), the constructive thing to do would be to ask whether the statement meant what you assumed it did, before saying you find it unacceptable. I know you are fully capable of being reasonable and thoughtful, so I am disappointed by the quality of your communication about this issue.[*] I would like us all to work well together in the WebKit project, and certainly being helpful about fixing regressions is an important part of that. But another important part is being reasonable even when you have a problem to report, and sometimes even when you feel provoked. Regards, Maciej [*] - And yes, I'm also disappointed by the quality of Alexey's communication - it would have been more constructive to start by asking for help investigating the regression from Chromium folks than to say what you quote above. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] WebKit2/Mac and C++11
Hello! This is just a friendly heads-up that the Mac specific parts of WebKit2 will soon start requiring C++11 features (move semantics and variadic templates being the two most important). Any recent version of Xcode (4.2 or later) should support this, and we're already building all of WebKit2 as C++11 on Mac anyway. - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit2/Mac and C++11
The future! Is now! :) Very exciting. I hope some day we can use C++11 for the rest of WebCore too. On Wed, Jan 30, 2013 at 12:17 PM, Anders Carlsson ander...@apple.com wrote: Hello! This is just a friendly heads-up that the Mac specific parts of WebKit2 will soon start requiring C++11 features (move semantics and variadic templates being the two most important). Any recent version of Xcode (4.2 or later) should support this, and we're already building all of WebKit2 as C++11 on Mac anyway. - Anders ___ 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] WebKit2/Mac and C++11
Thanks for the advance warning! :) - E On Wed, Jan 30, 2013 at 3:17 PM, Anders Carlsson ander...@apple.com wrote: Hello! This is just a friendly heads-up that the Mac specific parts of WebKit2 will soon start requiring C++11 features (move semantics and variadic templates being the two most important). Any recent version of Xcode (4.2 or later) should support this, and we're already building all of WebKit2 as C++11 on Mac anyway. - Anders ___ 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] WebKit Wishes
*I wish we only had one build system (it were easy to add/remove/move files).* * I believe changes like http://trac.webkit.org/changeset/74849 are an unhealthy sign for the project. Adam is not the only person who has chosen to empty files instead of removing them. The pain of updating 8 build system is so great, we jump through hoops to avoid it. Which means it took us months to move JavaScriptCore/wtf to WTF, and will take us years to kill WebCore/platform. I wish I felt like reviewers understood/trusted each other more. * *I’ve worked at both Apple and Google. The WebKit community is full of brilliant engineers. Yet I frequently feel a lack of trust in my (or others) judgement, or witness hot-headed remarks on bugs, lists or IRC. I don’t think it’s that people don’t trust me after nearly 8 years (!?) on this project, but rather that we forget, or fail to communicate trust among ourselves. Social problems are perhaps harder to solve for us technical types, but I worry that for many of us it’s just become “us” and “them” and we’ve stopped trying. I wish it were easy to work on feature branches. * *We have no good solution for features. For one-patch features, you do them on your own. For larger, you maybe use github or most likely you just land on trunk behind a #define. None of these have worked well. Some of this is the limits of SVN, but it should be trivial for someone to work on a new feature a long time, w/o endangering trunk or having massive merge pain every day. Other projects can do this. So should we. This is both impeding progress, and destabilizing trunk. I wish we didn’t have to worry about platforms we couldn’t test. * *It can’t be the job of the core maintainers to care about all the peripheral ports which contribute very little core code. Our code needs to be structured in such a manner that its easy for the core to march forward, while letting the ports catch up as they need to asynchronously. Platform support code shouldn’t even need to be in webkit.org! Porting webkit.org’s platform abstractions should be trivial, but core developers (which probably 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to worry about keeping all ports working. I wish that the tree always built and tested cleanly. * *Other (much larger) projects than WebKit accomplish this. Yet somehow Google pays 2 full-time engineers to watch our bots and yet we fail. I know other companies do similar. Automated rollouts is one solution. Branched-based development, or trybots are others. But at the size and scale we’re at now, every minute of a broken tree, is 100x or more minutes of potentially lost developer productivity. I wish I felt like I could follow what was going on (and trust WebKit to guard the web, instead of depending on Apple or Google). * *We’re the leading browser engine, with hundreds of committers, any of whom can add an API to 50% of internet browsers with a single commit. I wish we had a public process for feature/web-api review. I wish I felt like both major companies were willing participants in such. (Google has an internal process, but it sees limited use, in part because it’s powerless -- a ‘yes’ from our process is not a ‘yes’ from WebKit.) I want to feel like I can better observe and participate in the development of our web-api (and trust that it’s being done well!) without scanning every changeset just to be able to comment post-facto. (This is also reflected in the fact that the features enabled by the major Apple or Google ports are wildly different, with seemingly little rhyme or reason.) I wish WebCore was not trapped by Mac WebKit1’s legacy designs. * *WebKit2 is obviously a step towards the future. But until we can kill the Widget tree, the insanely fragile loader complexity, and the limits imposed by the least-common-denominator on classes like ResourceRequest, we’re still trapped in the past. One of the things I’ve learned in working on Chromium, is that we were wrong many years ago to fold our platform abstraction (Qt-implementation) and khtml into one library. In a sand-boxed multi-process world, the rendering library is just a hunk of code running the same on every platform. And platform code has no place in our core engine code (aka WebCore). I write less out of pain, and more out of hope for the future. I believe all of these are solvable problems, but I believe we need the will to solve them. Apple’s recent announcement of WebKit2 lockdown is clearly one attempt at some of these. But for the other 50% of WebKit developers who don’t work on WebKit2, locking down WebCore is not a good solution. I think we need to work together to bring about some of these dreams, for the short and long term health of the WebKit project. Thank you for listening. * ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Wishes
Thanks for sharing this. On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote: I wish we only had one build system (it were easy to add/remove/move files). I believe changes like http://trac.webkit.org/changeset/74849 are an unhealthy sign for the project. Adam is not the only person who has chosen to empty files instead of removing them. The pain of updating 8 build system is so great, we jump through hoops to avoid it. Which means it took us months to move JavaScriptCore/wtf to WTF, and will take us years to kill WebCore/platform. +1 This is a hard problem. It is a problem worth solving. Do you have more thoughts on this, particularly since you know quite well how both Xcode and gyp work? I suspect this is one of those things that it would be hard to achieve consensus on since there are so many stakeholders. But it may be fruitful to have a what if discussion about what this might look like. I wish I felt like reviewers understood/trusted each other more. I’ve worked at both Apple and Google. The WebKit community is full of brilliant engineers. Yet I frequently feel a lack of trust in my (or others) judgement, or witness hot-headed remarks on bugs, lists or IRC. I don’t think it’s that people don’t trust me after nearly 8 years (!?) on this project, but rather that we forget, or fail to communicate trust among ourselves. Social problems are perhaps harder to solve for us technical types, but I worry that for many of us it’s just become “us” and “them” and we’ve stopped trying. I wish it were easy to work on feature branches. We have no good solution for features. For one-patch features, you do them on your own. For larger, you maybe use github or most likely you just land on trunk behind a #define. None of these have worked well. Some of this is the limits of SVN, but it should be trivial for someone to work on a new feature a long time, w/o endangering trunk or having massive merge pain every day. Other projects can do this. So should we. This is both impeding progress, and destabilizing trunk. I've done this for JSC JIT optimization work before, and I think it worked quite well. The pain of merging the branch back into trunk was bad, but the reward was that I had ~2 months of time where I didn't have to worry about breaking other people's junk. Merging only took a week. One week of pain in return for 2 months of bliss? I'll take that. I concur that we can do better on this. I would especially love to see feature branching and merging follow a review process as if it were on trunk. Creating a branch involves a bug and a review. Patches that land on the branch are reviewed. Merging is either reviewed or rubber stamped. I wish we didn’t have to worry about platforms we couldn’t test. It can’t be the job of the core maintainers to care about all the peripheral ports which contribute very little core code. Our code needs to be structured in such a manner that its easy for the core to march forward, while letting the ports catch up as they need to asynchronously. Platform support code shouldn’t even need to be in webkit.org! Porting webkit.org’s platform abstractions should be trivial, but core developers (which probably 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to worry about keeping all ports working. +1 I wish that the tree always built and tested cleanly. Other (much larger) projects than WebKit accomplish this. Yet somehow Google pays 2 full-time engineers to watch our bots and yet we fail. I know other companies do similar. Automated rollouts is one solution. Branched-based development, or trybots are others. But at the size and scale we’re at now, every minute of a broken tree, is 100x or more minutes of potentially lost developer productivity. I actually think this just goes along with the territory. Browser engines are hard. Browser engines that achieve the configurability and portability of WebKit: even harder. Maybe I'm naive but I think we're doing quite well on this front given the circumstances. I also suspect that this problem ought to be diminished with your other suggestions, particularly having more branch-based development, and especially if there was a magical way to simplify building. I wish I felt like I could follow what was going on (and trust WebKit to guard the web, instead of depending on Apple or Google). We’re the leading browser engine, with hundreds of committers, any of whom can add an API to 50% of internet browsers with a single commit. I wish we had a public process for feature/web-api review. I wish I felt like both major companies were willing participants in such. (Google has an internal process, but it sees limited use, in part because it’s powerless -- a ‘yes’ from our process is not a ‘yes’ from WebKit.) I want to feel like I can better observe
Re: [webkit-dev] WebKit Wishes
Hi Eric, These are great thoughts. I agree with you on all points. One informative comment below: On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote: I wish we only had one build system (it were easy to add/remove/move files). I believe changes like http://trac.webkit.org/changeset/74849 are an unhealthy sign for the project. Adam is not the only person who has chosen to empty files instead of removing them. The pain of updating 8 build system is so great, we jump through hoops to avoid it. Which means it took us months to move JavaScriptCore/wtf to WTF, and will take us years to kill WebCore/platform. I wish I felt like reviewers understood/trusted each other more. I’ve worked at both Apple and Google. The WebKit community is full of brilliant engineers. Yet I frequently feel a lack of trust in my (or others) judgement, or witness hot-headed remarks on bugs, lists or IRC. I don’t think it’s that people don’t trust me after nearly 8 years (!?) on this project, but rather that we forget, or fail to communicate trust among ourselves. Social problems are perhaps harder to solve for us technical types, but I worry that for many of us it’s just become “us” and “them” and we’ve stopped trying. I wish it were easy to work on feature branches. We have no good solution for features. For one-patch features, you do them on your own. For larger, you maybe use github or most likely you just land on trunk behind a #define. None of these have worked well. Some of this is the limits of SVN, but it should be trivial for someone to work on a new feature a long time, w/o endangering trunk or having massive merge pain every day. Other projects can do this. So should we. This is both impeding progress, and destabilizing trunk. I wish we didn’t have to worry about platforms we couldn’t test. It can’t be the job of the core maintainers to care about all the peripheral ports which contribute very little core code. Our code needs to be structured in such a manner that its easy for the core to march forward, while letting the ports catch up as they need to asynchronously. Platform support code shouldn’t even need to be in webkit.org! Porting webkit.org’s platform abstractions should be trivial, but core developers (which probably 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to worry about keeping all ports working. I wish that the tree always built and tested cleanly. Other (much larger) projects than WebKit accomplish this. Yet somehow Google pays 2 full-time engineers to watch our bots and yet we fail. I know other companies do similar. Automated rollouts is one solution. Branched-based development, or trybots are others. But at the size and scale we’re at now, every minute of a broken tree, is 100x or more minutes of potentially lost developer productivity. I wish I felt like I could follow what was going on (and trust WebKit to guard the web, instead of depending on Apple or Google). We’re the leading browser engine, with hundreds of committers, any of whom can add an API to 50% of internet browsers with a single commit. I wish we had a public process for feature/web-api review. I wish I felt like both major companies were willing participants in such. (Google has an internal process, but it sees limited use, in part because it’s powerless -- a ‘yes’ from our process is not a ‘yes’ from WebKit.) I want to feel like I can better observe and participate in the development of our web-api (and trust that it’s being done well!) without scanning every changeset just to be able to comment post-facto. (This is also reflected in the fact that the features enabled by the major Apple or Google ports are wildly different, with seemingly little rhyme or reason.) I wish WebCore was not trapped by Mac WebKit1’s legacy designs. WebKit2 is obviously a step towards the future. But until we can kill the Widget tree, the insanely fragile loader complexity, and the limits imposed by the least-common-denominator on classes like ResourceRequest, we’re still trapped in the past. One of the things I’ve learned in working on Chromium, is that we were wrong many years ago to fold our platform abstraction (Qt-implementation) and khtml into one library. In a sand-boxed multi-process world, the rendering library is just a hunk of code running the same on every platform. And platform code has no place in our core engine code (aka WebCore). In designing WebKit2, we tried to avoid some mistakes in the WebKit1 Mac API design (such as exposing the underlying network library, exposing our NSView hierarchy as part of the API, and giving too much salience to frames). While we can't remove those parts of the API entirely, if we get more Mac API clients onto WebKit2, then the performance of these details of the WK1 API becomes less critical,
Re: [webkit-dev] WebKit Wishes
Hi Eric, On Wed, Jan 30, 2013 at 10:28 PM, Eric Seidel e...@webkit.org wrote: I wish we didn’t have to worry about platforms we couldn’t test. It can’t be the job of the core maintainers to care about all the peripheral ports which contribute very little core code. Our code needs to be structured in such a manner that its easy for the core to march forward, while letting the ports catch up as they need to asynchronously. Platform support code shouldn’t even need to be in webkit.org! Porting webkit.org’s platform abstractions should be trivial, but core developers (which probably 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to worry about keeping all ports working. I agree this is a hard problem. Also a stressful situation to get oneself into. Coming up with ways to allow port code to survive core changes would be excellent for everyone, even for the small ports people who hack on the core and also cannot easily test Mac WK2, Chromium Linux or any other port. I write less out of pain, and more out of hope for the future. I believe all of these are solvable problems, but I believe we need the will to solve them. Apple’s recent announcement of WebKit2 lockdown is clearly one attempt at some of these. But for the other 50% of WebKit developers who don’t work on WebKit2, locking down WebCore is not a good solution. I agree the WebKit2 lockdown is one attempt at solving this, but hopefully we can agree it's not a particularly innovative one. Breaking builds and allowing bugs to pile up while they are fixed is a nasty situation, one that historically we have tried really hard to avoid for very well known reasons. I understand in the final analysis allowing the core to move fast could be more important than having an healthy ecosystem of minor ports without huge teams behind them, but I really hope that this is only a temporary solution and that in the future we'll be able to find better solutions like those that you suggest in your email. Also, on a personal note, I've been around for enough years to remember the time when people trying to get ports started were eagerly welcomed by Apple employees, who would go out of their way to help us get started, review our patches when we had no reviewers in our team, patiently explain this or that part of the code, etc. I made sure to tell everyone I knew that WebKit was one of the most well managed open source projects in existence, one of those rare combinations of success and fidelity to some of the best values that open source supposedly represents. It is with a bit of sadness that years later I find that the same project (even the same people) now has a very different attitude, and that long term contributors who I believe have modestly helped to make this project more robust and popular are mostly seen as part of a problem instead of as part of its thriving community. I suppose wild success has some unfortunate costs. In any case, I don't want to end on a pessimistic note. I'm sure there's enough brilliance in this community to come up with better solutions for everyone, including future ports that do not exist yet but that might be very relevant in this world that moves at breakneck pace. Cheers, Xan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Wishes
On Wed, Jan 30, 2013 at 1:28 PM, Eric Seidel e...@webkit.org wrote: * I wish I felt like reviewers understood/trusted each other more. * *I’ve worked at both Apple and Google. The WebKit community is full of brilliant engineers. Yet I frequently feel a lack of trust in my (or others) judgement, or witness hot-headed remarks on bugs, lists or IRC. I don’t think it’s that people don’t trust me after nearly 8 years (!?) on this project, but rather that we forget, or fail to communicate trust among ourselves. Social problems are perhaps harder to solve for us technical types, but I worry that for many of us it’s just become “us” and “them” and we’ve stopped trying.* This is a big one for me (as you would've guessed :). All others seem surmountable if only we could somehow fix this. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Wishes
Hi, Am 30.01.2013 um 22:28 schrieb Eric Seidel: I wish we only had one build system (it were easy to add/remove/move files). I've created CMake files for two different ports at [1] and [2] already, but did't get positive feedback from the port-maintainer. So I stopped working on it. If any port is still interested in switching to CMake I'd like to help creating the required files, but only with feedback of the port-maintainer. -- Patrick [1] https://bugs.webkit.org/show_bug.cgi?id=72816 [2] https://bugs.webkit.org/show_bug.cgi?id=73100 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Wishes
On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote: Thanks for sharing this. On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote: I wish we only had one build system (it were easy to add/remove/move files). I believe changes like http://trac.webkit.org/changeset/74849 are an unhealthy sign for the project. Adam is not the only person who has chosen to empty files instead of removing them. The pain of updating 8 build system is so great, we jump through hoops to avoid it. Which means it took us months to move JavaScriptCore/wtf to WTF, and will take us years to kill WebCore/platform. +1 This is a hard problem. It is a problem worth solving. Do you have more thoughts on this, particularly since you know quite well how both Xcode and gyp work? I suspect this is one of those things that it would be hard to achieve consensus on since there are so many stakeholders. But it may be fruitful to have a what if discussion about what this might look like. I think we can solve this problem if we agree that we want to. I think we haven't in the past mostly because we couldn't reach a consensus that it was worth solving enough to really try. I would love to see this fixed and would be glad to work on it. I think we should at least pursue this far enough to fully understand what our options are and what the costs and tradeoffs might be; does anyone disagree, and is anyone else willing to help pitch in? I think there are several possible ways we could solve this. One would be to switch to a common meta-build system. My understanding is that Apple's internal production build processes impose certain constraints here that I don't fully understand, but I know we've discussed the possibility of checking in generated project files as a workaround. Maybe there are other options as well to those constraints? I would love to discuss this further w/ someone from Apple ... (Also, just to get this out of the way, I don't think gyp needs to be the solution). Another alternative would be to write a script that did support at least the common use cases (add/move/delete files). There have been attempts in the past, but they have foundered on at least some perceived skepticism over how well this would work w/ XCode. That said, I don't think we've really pushed this to see. At some point this script might turn into a meta-meta-build system, which might be silly but also be the shortest path to the finish line. I suggest if there is interest in this we can start a new thread to discuss further ... -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Removing ENABLE(WEB_INTENTS) code
Hi, I'd like to delete all the ENABLE(WEB_INTENTS) code. As far as I know, nobody ever shipped this and nobody intents to. Please speak up if you'd like that code to stick around. Nico ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Common build system (was Re: WebKit Wishes)
On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote: Thanks for sharing this. On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote: I wish we only had one build system (it were easy to add/remove/move files). I believe changes like http://trac.webkit.org/changeset/74849 are an unhealthy sign for the project. Adam is not the only person who has chosen to empty files instead of removing them. The pain of updating 8 build system is so great, we jump through hoops to avoid it. Which means it took us months to move JavaScriptCore/wtf to WTF, and will take us years to kill WebCore/platform. +1 This is a hard problem. It is a problem worth solving. Do you have more thoughts on this, particularly since you know quite well how both Xcode and gyp work? I suspect this is one of those things that it would be hard to achieve consensus on since there are so many stakeholders. But it may be fruitful to have a what if discussion about what this might look like. I think we can solve this problem if we agree that we want to. I think we haven't in the past mostly because we couldn't reach a consensus that it was worth solving enough to really try. I would love to see this fixed and would be glad to work on it. I think we should at least pursue this far enough to fully understand what our options are and what the costs and tradeoffs might be; does anyone disagree, and is anyone else willing to help pitch in? I think there are several possible ways we could solve this. One would be to switch to a common meta-build system. My understanding is that Apple's internal production build processes impose certain constraints here that I don't fully understand, but I know we've discussed the possibility of checking in generated project files as a workaround. Maybe there are other options as well to those constraints? I would love to discuss this further w/ someone from Apple ... It's far simplest for us if: (a) There is an Xcode project (or a Makefile) that builds the Mac port checked in to source control. (b) The generated project invokes only tools that are part of the default Mac OS X install. It may not be completely impossible to violate these requirements but it will require a lot of bureaucracy. (Also, just to get this out of the way, I don't think gyp needs to be the solution). Another alternative would be to write a script that did support at least the common use cases (add/move/delete files). There have been attempts in the past, but they have foundered on at least some perceived skepticism over how well this would work w/ XCode. That said, I don't think we've really pushed this to see. At some point this script might turn into a meta-meta-build system, which might be silly but also be the shortest path to the finish line. I suggest if there is interest in this we can start a new thread to discuss further ... My preference would be to use a common meta-build system with a comfortably human-readable and human-editable syntax, and checked in generated project files for those ports that need them. I think a key to making this work is to get Chromium and the Apple Mac port onto a common build system, which will probably require both Google and Apple ponying up at least one person to work on this project for a reasonable period of time. I think the plausible meta-build-systems to use would be CMake and Gyp, but in both cases it may be necessary to modify them to work well for everyone. I'd also like to add that I think a key related issue to common build system is common feature configuration. The many different ways ports control their feature flags is super confusing. I've long wanted to implement common configuration management, but have not had time. Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
Hi ! I'd also like to add that I think a key related issue to common build system is common feature configuration. The many different ways ports control their feature flags is super confusing. I've long wanted to implement common configuration management, but have not had time. I think this would be a nice related project, but I wouldn't necessarily want to lump the two goals together without understanding what we'd be shooting for first. From what I know, CMake's support for feature configuration is much more mature than what you can do w/ GYP. It could certainly be a good motivator, though. My recent e-mail ( https://lists.webkit.org/pipermail/webkit-dev/2013-January/023368.html) to the list was an attempt to address the feature configuration problem - assuming that that a single build system is not an option. The idea was to use C macros to describe the rules for feature configurations and figure out a way to populate them to the various build systems (potentially using a C precompiler to eval the macros). Some of feature configuration flags does not need to be exposed to the build system these can just be #include-d to the source. I do not think that this is a technical superiors solution but perhaps it worth considering to discuss as it relies on tools and syntax we happened to already agree on and I felt that what might come out of it is better what we have now. Best, Laszlo ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Feature announcement: Font Load Events
Hello, I would like to let you know that I plan to add support for the FontLoader interface to WebCore. It provides ways to detect font loading is actually occurred and when the loading finished. The spec is here: http://dev.w3.org/csswg/css3-fonts/#font-load-events Here is the tracking bug: https://bugs.webkit.org/show_bug.cgi?id=98395 Let me know if you have any questions or comments. Best regards, Kunihiko ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On Jan 30, 2013, at 5:46 PM, Laszlo Gombos laszlo.gom...@gmail.com wrote: Hi ! I'd also like to add that I think a key related issue to common build system is common feature configuration. The many different ways ports control their feature flags is super confusing. I've long wanted to implement common configuration management, but have not had time. I think this would be a nice related project, but I wouldn't necessarily want to lump the two goals together without understanding what we'd be shooting for first. From what I know, CMake's support for feature configuration is much more mature than what you can do w/ GYP. It could certainly be a good motivator, though. My recent e-mail (https://lists.webkit.org/pipermail/webkit-dev/2013-January/023368.html) to the list was an attempt to address the feature configuration problem - assuming that that a single build system is not an option. The idea was to use C macros to describe the rules for feature configurations and figure out a way to populate them to the various build systems (potentially using a C precompiler to eval the macros). Some of feature configuration flags does not need to be exposed to the build system these can just be #include-d to the source. I do not think that this is a technical superiors solution but perhaps it worth considering to discuss as it relies on tools and syntax we happened to already agree on and I felt that what might come out of it is better what we have now. My past suggestion: have a separate Port.h header for every file, which turns on its set of PLATFORM, ENABLE and USE macros. Platform.h includes exclusively definitions of things that can be inferred from the build environment (like CPU, COMPILER, OS). Port.h files could delegate. So for example we might have: mac/Port.h -- cocoa/Port.h -- apple/Port.h -- default/Port.h the default Port.h file would include the WebKit project's shared recommendations for what features should be on or off. If a flag ends up here and we don't know of any port disabling it, we might just remove it. Including the right Port.h would be handled by include path magic. That's my idea in a nutshell. It would put all configuration logic into the preprocessor instead of a mix of the preprocessor and various build systems. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On Thu, Jan 31, 2013 at 1:15 AM, Maciej Stachowiak m...@apple.com wrote: On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote: Thanks for sharing this. On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote: I wish we only had one build system (it were easy to add/remove/move files). I believe changes like http://trac.webkit.org/changeset/74849 are an unhealthy sign for the project. Adam is not the only person who has chosen to empty files instead of removing them. The pain of updating 8 build system is so great, we jump through hoops to avoid it. Which means it took us months to move JavaScriptCore/wtf to WTF, and will take us years to kill WebCore/platform. +1 This is a hard problem. It is a problem worth solving. Do you have more thoughts on this, particularly since you know quite well how both Xcode and gyp work? I suspect this is one of those things that it would be hard to achieve consensus on since there are so many stakeholders. But it may be fruitful to have a what if discussion about what this might look like. I think we can solve this problem if we agree that we want to. I think we haven't in the past mostly because we couldn't reach a consensus that it was worth solving enough to really try. I would love to see this fixed and would be glad to work on it. I think we should at least pursue this far enough to fully understand what our options are and what the costs and tradeoffs might be; does anyone disagree, and is anyone else willing to help pitch in? I think there are several possible ways we could solve this. One would be to switch to a common meta-build system. My understanding is that Apple's internal production build processes impose certain constraints here that I don't fully understand, but I know we've discussed the possibility of checking in generated project files as a workaround. Maybe there are other options as well to those constraints? I would love to discuss this further w/ someone from Apple ... It's far simplest for us if: (a) There is an Xcode project (or a Makefile) that builds the Mac port checked in to source control. (b) The generated project invokes only tools that are part of the default Mac OS X install. Another desirable property would be to move to a more automatic way of handling exported symbols: Currently each port that depends on this feature has its own .exp file or similar. I think if we could move to something that would allow for changing WebCore API without having to touch all those files, e.g. by consistently using WEBCORE_EXPORT macros would be a big win best -jochen It may not be completely impossible to violate these requirements but it will require a lot of bureaucracy. (Also, just to get this out of the way, I don't think gyp needs to be the solution). Another alternative would be to write a script that did support at least the common use cases (add/move/delete files). There have been attempts in the past, but they have foundered on at least some perceived skepticism over how well this would work w/ XCode. That said, I don't think we've really pushed this to see. At some point this script might turn into a meta-meta-build system, which might be silly but also be the shortest path to the finish line. I suggest if there is interest in this we can start a new thread to discuss further ... My preference would be to use a common meta-build system with a comfortably human-readable and human-editable syntax, and checked in generated project files for those ports that need them. I think a key to making this work is to get Chromium and the Apple Mac port onto a common build system, which will probably require both Google and Apple ponying up at least one person to work on this project for a reasonable period of time. I think the plausible meta-build-systems to use would be CMake and Gyp, but in both cases it may be necessary to modify them to work well for everyone. I'd also like to add that I think a key related issue to common build system is common feature configuration. The many different ways ports control their feature flags is super confusing. I've long wanted to implement common configuration management, but have not had time. Cheers, Maciej ___ 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] WebKit Wishes
On Wed, Jan 30, 2013 at 10:28 PM, Eric Seidel e...@webkit.org wrote: I wish it were easy to work on feature branches. We have no good solution for features. For one-patch features, you do them on your own. For larger, you maybe use github or most likely you just land on trunk behind a #define. None of these have worked well. Some of this is the limits of SVN, but it should be trivial for someone to work on a new feature a long time, w/o endangering trunk or having massive merge pain every day. Other projects can do this. So should we. This is both impeding progress, and destabilizing trunk. I like the idea of developing larger features or multi-patch changes on a branch. Relating this with the next two wishes, I'd support this approach if the whole patchset would be tested on trunk for every port with every change that's made. The port maintainers (even those working on small ports) could then fix any build failures or make changes to the platform-specific code as necessary to make the merging of the branch a minimal annoyance for everyone. Similarly, when the work on the branch is deemed finished and there are still ports that would break upon merging, a sensible time frame, for instance 2 work days, would be given for the port maintainers to come up with fixes before merging the branch regardless of the consequences. The point I'd like to expose is that when using branches, landing broken branches on broken trunk leads nowhere. That's why it's important to maintain a building and working trunk, but give all the ports the possibility of fixing any outstanding issues in the branch before merging, so the trunk doesn't break (and the breakage loop is entered). Regards, -Z ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
