Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs
15 янв. 2014 г., в 23:02, Ryosuke Niwa rn...@webkit.org написал(а): I think that it's good to try not dumping build failures into comments right away, and to see what happens. As for not showing style bot failures, it seems almost certain that this will make them substantially more annoying to work with. Can you describe the workflow for patch author and reviewer to deal with style bot warnings when they are not inline? Manually finding relevant lines by number can't work. I agree with Tim that dumping all tested paths along with style warnings is silly. How hard would it be it to get rid of that? The workflow is to click on the bubble to see the style errors. e.g. https://webkit-queues.appspot.com/results/6544662978363392 Seems like that would require everyone to manually match errors to code lines indeed, so I object against making this change for style checker warnings. - WBR, Alexey Proskuryakov___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Importing W3C tests for HTML template elements
I created a bug to track this (serve imported w3c tests using wptserve: https://bugs.webkit.org/show_bug.cgi?id=127094). I also plan to work on merging Blink patches to allow checking testharness-based tests without the use of any -expected file: https://bugs.webkit.org/show_bug.cgi?id=127095. 2014/1/6 Dirk Pranke dpra...@chromium.org Ryosuke and I discussed this a bit over IRC. Ryosuke's main concern was that supporting multiple document roots adds a fair amount of complexity to NRWT. Conceptually, it's probably easier to add support to run the W3C's new server (known as wptserve) and then maybe use it for *all* imported tests from the W3C. If it turns out that wptserve is too slow, and you would prefer to run only some of the directories over http (i.e., the 10k+ CSS tests don't need http), you'll probably need to modify how wptserve is run (and NRWT) as well, anyway, so the patch would be different. Ryosuke, please let me know if I've misstated your thinking at all. -- Dirk On Mon, Jan 6, 2014 at 11:23 AM, Ryosuke Niwa rn...@webkit.org wrote: I don't think we should do this given that the python server has been added to W3C testing harness, and they're gonna convert all existing tests to use that instead: http://lists.w3.org/Archives/Public/public-test-infra/2014JanMar/.html We should simply wait for that effort to take place and add a support for the python server instead. - R. Niwa On Fri, Dec 6, 2013 at 12:25 AM, youenn fablet youe...@gmail.com wrote: As long as the newly imported tests use relative URLs, alias may be used as a workaround. I will give it a try. Bug entry is at https://bugs.webkit.org/show_bug.cgi?id=125339 Any further help appreciated, Youenn 2013/12/6 Darin Adler da...@apple.com If that's really ends up being super hard we can always put yet another third-party or imported directory inside the http directory as previously suggested. it's annoying to have three different places for imported tests and code, but not something I want to hold us up for a long time. -- Darin Sent from my iPhone On Dec 5, 2013, at 5:51 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Dec 4, 2013 at 11:19 AM, Darin Adler da...@apple.com wrote: On Dec 4, 2013, at 6:48 AM, youenn fablet youe...@gmail.com wrote: I am planning to add some XHR tests from https://github.com/w3c/web-platform-tests. My initial plan was to add them in a subdirectory of LayoutTests/http/tests/w3c. If adding them into LayoutTests/imported/w3c, that would probably require updating the test scripts to start/stop the HTTP test server for that particular sub-folder. Any preference? I’d prefer LayoutTests/imported/w3c. Although I’m not so happy about the different terminology we are using for “imported” vs. “ThirdParty”, which seems like the same concept at the top level of the directory structure. One trickiness to it is that we don't currently run any HTTP test in parallel and the document root of the HTTP server is set to LayoutTests/http/tests so we might need to modify that or restart the HTTP server whenever we're running HTTP tests outside of LayoutTests/http. - 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] Proposal: Stop EWS bot commenting in bugs
On Jan 16, 2014, at 2:28 AM, Alexey Proskuryakov a...@webkit.org wrote: 15 янв. 2014 г., в 23:02, Ryosuke Niwa rn...@webkit.org написал(а): I think that it's good to try not dumping build failures into comments right away, and to see what happens. As for not showing style bot failures, it seems almost certain that this will make them substantially more annoying to work with. Can you describe the workflow for patch author and reviewer to deal with style bot warnings when they are not inline? Manually finding relevant lines by number can't work. I agree with Tim that dumping all tested paths along with style warnings is silly. How hard would it be it to get rid of that? The workflow is to click on the bubble to see the style errors. e.g. https://webkit-queues.appspot.com/results/6544662978363392 Seems like that would require everyone to manually match errors to code lines indeed, so I object against making this change for style checker warnings. - WBR, Alexey Proskuryakov Yeah, seeing the style warnings as a comment (which also causes them to show up in the patch review) is helpful. I was just complaining about the python path spew it also includes. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Nix future
Hi Webkittens, During the last weeks, people interested in using or experimenting with Nix have been asking us about the upstreaming process, how long Nix will be supported, etc. The answer has always been in the lines of “we're working hard to make it last for a long time” -- and that was true. However, now we have a definitive answer, as this week we were notified that the resources of the Nix project will be redirected to other areas/projects. In practice, it means we won't be able to keep our efforts with its development and the upstreaming process and all activities related to Nix are going to stop by the end of this month[1]. We are going to remove Nix from trunk in the next days but the code will remain on our usual github[2] page, for the interested parties. If you have any question or specific interest on Nix, please don't hesitate to contact us. We would like to thank especially the Szeged team for developing new features, tests, bugfixes, Benjamin Poulain and others from the Apple team and WebKit community as a whole for reviewing and supporting the upstreaming process. Regards, Nix Team [1] https://www.youtube.com/watch?v=JSUIQgEVDM4 [2] https://github.com/WebKitNix/webkitnix ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Nix future
Hi, That is sad, it was great working with Nix. Having a low maintenance port was a fantastic experience. Good luck with your next adventures. Benjamin On 16/01/2014 11:20, Luciano Wolf wrote: Hi Webkittens, During the last weeks, people interested in using or experimenting with Nix have been asking us about the upstreaming process, how long Nix will be supported, etc. The answer has always been in the lines of “we're working hard to make it last for a long time” -- and that was true. However, now we have a definitive answer, as this week we were notified that the resources of the Nix project will be redirected to other areas/projects. In practice, it means we won't be able to keep our efforts with its development and the upstreaming process and all activities related to Nix are going to stop by the end of this month[1]. We are going to remove Nix from trunk in the next days but the code will remain on our usual github[2] page, for the interested parties. If you have any question or specific interest on Nix, please don't hesitate to contact us. We would like to thank especially the Szeged team for developing new features, tests, bugfixes, Benjamin Poulain and others from the Apple team and WebKit community as a whole for reviewing and supporting the upstreaming process. Regards, Nix Team [1] https://www.youtube.com/watch?v=JSUIQgEVDM4 [2] https://github.com/WebKitNix/webkitnix ___ 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] Proposal: Stop EWS bot commenting in bugs
Okay, let's remove the python paths but keep the style error messages until we can improve the EWS infrastructure. - R. Niwa On Thu, Jan 16, 2014 at 9:41 AM, Timothy Hatcher timo...@apple.com wrote: On Jan 16, 2014, at 2:28 AM, Alexey Proskuryakov a...@webkit.org wrote: 15 янв. 2014 г., в 23:02, Ryosuke Niwa rn...@webkit.org написал(а): I think that it's good to try not dumping build failures into comments right away, and to see what happens. As for not showing style bot failures, it seems almost certain that this will make them substantially more annoying to work with. Can you describe the workflow for patch author and reviewer to deal with style bot warnings when they are not inline? Manually finding relevant lines by number can't work. I agree with Tim that dumping all tested paths along with style warnings is silly. How hard would it be it to get rid of that? The workflow is to click on the bubble to see the style errors. e.g. https://webkit-queues.appspot.com/results/6544662978363392 Seems like that would require everyone to manually match errors to code lines indeed, so I object against making this change for style checker warnings. - WBR, Alexey Proskuryakov Yeah, seeing the style warnings as a comment (which also causes them to show up in the patch review) is helpful. I was just complaining about the python path spew it also includes. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] OVERRIDE and FINAL are GONE
Hi floks! Since all compilers we require now support the real override and final keywords, we’ve gone ahead and removed the uppercase macros. From now on, just use the lowercase keywords! Thanks, - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
