[webkit-dev] Please don't leave entries for rebaseline in TestExpectation files
On Wednesday, 20 March 2013, Ryosuke Niwa wrote: Please don't add lines to TestExpectations saying that they just need rebaselines and then leave. OK. That means I will have to pull the new results from the bots, which is fine - but in the case of the Mac port (and any other bot that does not run pixel tests) the result will be that trunk will get fresh text results but retain stale png results. If that is OK then you need to publish that information somewhere as I suspect I'm not the only contributor who has hesitated to make Mac's test results inconsistent. That would reduce the test coverage we have, and effectively disables the test. If you're adding those entires, please be sure to remove them ASAP. Better yet, don't add them unless you have to rebaseline hundreds of tests. It's not acceptable to leave those entries in TestExpectations for days. We've batted back and forth on this list for at least a year on the correct approach for landing and rebaselining. My approach is to land results for the platform that I build, suppress tests that require rebaselining on other platforms, and open a bug so sheriffs can add/rebaseline results as appropriate. My impression from recent discussion on this topic was that this was the way that worked best for everybody.I used to pull results from the bots where possible but creating inconsistency between png/text results is not good. Presumably this will be discussed at the contributors' meeting - it would be good to make sure that all the relevant people required for consensus on this topic can attend the discussion and settle this once and for all! ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't leave entries for rebaseline in TestExpectation files
On Wed, Mar 20, 2013 at 11:46 PM, Robert Hogan li...@roberthogan.netwrote: On Wednesday, 20 March 2013, Ryosuke Niwa wrote: Please don't add lines to TestExpectations saying that they just need rebaselines and then leave. OK. That means I will have to pull the new results from the bots, which is fine - but in the case of the Mac port (and any other bot that does not run pixel tests) the result will be that trunk will get fresh text results but retain stale png results. I suspect by and then leave Ryosuke meant and never come back. It seems reasonable to me to check in and then wait a sufficient amount of time for the bots to cycle fully before using garden-o-matic to pull the correct baselines. This would mean we might have people leaving a [pkasting] Will rebaseline this test before Mar. 22, 2013 line on some expectations for a day or two, just not forever. We've batted back and forth on this list for at least a year on the correct approach for landing and rebaselining. My approach is to land results for the platform that I build, suppress tests that require rebaselining on other platforms, and open a bug so sheriffs can add/rebaseline results as appropriate. It's certainly nicer than not landing any expectations :). But as the current Chromium WebKit sheriff, I just spent a few hours rebaselining a lot of these sorts of things in the Chromium expectations, some of which had been around for months. It's easy for these sorts of needs rebaseline bugs to get lost in the shuffle, and in a few cases, I couldn't determine if needs rebaseline was still correct due to further changes that had happened since. For these reasons, the original change author is in the best position to ensure the right rebaselining happens quickly, although I do realize that this is a nontrivial burden to place on change authors. I don't know if that means we should say do this if you can, but OK if not, or what. My impression from recent discussion on this topic was that this was the way that worked best for everybody.I used to pull results from the bots where possible but creating inconsistency between png/text results is not good. As long as the relevant bots have all cycled past the change in question, your checkout contains all the relevant LayoutTest subdirectories, and you've updated to ToT, I believe garden-o-matic can correctly rebaseline any of the ports it supports, regardless of whether you can build/run those ports locally. Inconsistencies I've seen have been a result of non-updated checkouts or non-cycled bots. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't leave entries for rebaseline in TestExpectation files
To give you a perspective on how bad the current system is, just while I was removing those 30 entires, I've found out that fast/css-generated-content/table-row-group-to-inline.html has regressed since it was first added. This regression should have caught by people running pixel tests only if we had rebaselined it promptly. I have seen dozens of cases where we had introduced regressions that would have been caught by existing layout tests only if they had not been marked flaky, failing, etc... On Wed, Mar 20, 2013 at 11:46 PM, Robert Hogan li...@roberthogan.netwrote: On Wednesday, 20 March 2013, Ryosuke Niwa wrote: Please don't add lines to TestExpectations saying that they just need rebaselines and then leave. OK. That means I will have to pull the new results from the bots, which is fine - but in the case of the Mac port (and any other bot that does not run pixel tests) the result will be that trunk will get fresh text results but retain stale png results. If that is OK then you need to publish that information somewhere as I suspect I'm not the only contributor who has hesitated to make Mac's test results inconsistent. That's what non-Chromium ports do anyways. That would reduce the test coverage we have, and effectively disables the test. If you're adding those entires, please be sure to remove them ASAP. Better yet, don't add them unless you have to rebaseline hundreds of tests. It's not acceptable to leave those entries in TestExpectations for days. We've batted back and forth on this list for at least a year on the correct approach for landing and rebaselining. My approach is to land results for the platform that I build, suppress tests that require rebaselining on other platforms, and open a bug so sheriffs can add/rebaseline results as appropriate. I don't think this approach scales. My impression from recent discussion on this topic was that this was the way that worked best for everybody. That was NOT my impression. I made it pretty clear that I dislike this approach. If you're referring to https://lists.webkit.org/pipermail/webkit-dev/2013-February/023960.html, then most of people who replied on that thread hadn't even contributed much code to WebCore, and I highly doubt that their opinions represent the whole WebKit community. I used to pull results from the bots where possible but creating inconsistency between png/text results is not good. It is unfortunate but it's much better than losing the complete test coverage. Presumably this will be discussed at the contributors' meeting - it would be good to make sure that all the relevant people required for consensus on this topic can attend the discussion and settle this once and for all! Definitely. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't leave entries for rebaseline in TestExpectation files
On Thursday, 21 March 2013, Ryosuke Niwa wrote: I used to pull results from the bots where possible but creating inconsistency between png/text results is not good. It is unfortunate but it's much better than losing the complete test coverage. If that's the case then I'm happy to land whatever garden-o-matic pulls in or I can sweep from the bots, even if it means that png results for Mac, Qt, et al. go bad as a result. I guess we will always have ports whose bots do not run pixel tests so if those ports are happy to live with the downsides of doing that then there really is no obstacle to authors owning the job of updating the baselines for all ports when they land a change. IMHO ports who don't run pixel tests would be better off deleting any png results they have in the tree. Is there a reason Mac hasn't done that? Don't you get lots of failures when you run pixel tests locally? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't leave entries for rebaseline in TestExpectation files
On Thu, Mar 21, 2013 at 1:31 AM, Robert Hogan li...@roberthogan.net wrote: On Thursday, 21 March 2013, Ryosuke Niwa wrote: I used to pull results from the bots where possible but creating inconsistency between png/text results is not good. It is unfortunate but it's much better than losing the complete test coverage. If that's the case then I'm happy to land whatever garden-o-matic pulls in or I can sweep from the bots, even if it means that png results for Mac, Qt, et al. go bad as a result. I guess we will always have ports whose bots do not run pixel tests so if those ports are happy to live with the downsides of doing that then there really is no obstacle to authors owning the job of updating the baselines for all ports when they land a change. IMHO ports who don't run pixel tests would be better off deleting any png results they have in the tree. Is there a reason Mac hasn't done that? Don't you get lots of failures when you run pixel tests locally? Yes, but I'd argue that it's better than losing the test coverage. By the way, we can easily address this problem by always generating pixel results for unexpectedly failing tests. Namely, we can force --pixel when we're retrying tests. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] APNG support
On Thursday 21 March 2013, Max Stepin wrote: What do you think? I posted the patch here: https://bugs.webkit.org/show_bug.cgi?id=17022 I don't mind. APNG is a nice simple format. GIF has limitations and MNG is almost inherently broken. To support it though, you need to make sure the patch is very clean. We can't be sure Chrome or Safari will want to enable it, and for Qt we can't control it (depends on the system libpng version after all). So the patch will probably need to extra clean and nice to convince everybody it will not be a maintenance burden later. But for its worth; I would like to see it go in at some point. Cheers `Allan (carewolf) ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] APNG support
Chromium is not interested in supporting APNG. I'm not opposed to landing this patch if other ports are interested in supporting APNG. Adam On Mar 21, 2013 4:28 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: On Thursday 21 March 2013, Max Stepin wrote: What do you think? I posted the patch here: https://bugs.webkit.org/show_bug.cgi?id=17022 I don't mind. APNG is a nice simple format. GIF has limitations and MNG is almost inherently broken. To support it though, you need to make sure the patch is very clean. We can't be sure Chrome or Safari will want to enable it, and for Qt we can't control it (depends on the system libpng version after all). So the patch will probably need to extra clean and nice to convince everybody it will not be a maintenance burden later. But for its worth; I would like to see it go in at some point. Cheers `Allan (carewolf) ___ 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] Please don't leave entries for rebaseline in TestExpectation files
On Thursday, 21 March 2013, Ryosuke Niwa wrote:
On Thu, Mar 21, 2013 at 1:31 AM, Robert Hogan
li...@roberthogan.netjavascript:_e({}, 'cvml', 'li...@roberthogan.net');
wrote:
On Thursday, 21 March 2013, Ryosuke Niwa wrote:
I used to pull results from the bots where possible but creating
inconsistency between png/text results is not good.
It is unfortunate but it's much better than losing the complete test
coverage.
If that's the case then I'm happy to land whatever garden-o-matic pulls
in or I can sweep from the bots, even if it means that png results for Mac,
Qt, et al. go bad as a result.
I guess we will always have ports whose bots do not run pixel tests so if
those ports are happy to live with the downsides of doing that then there
really is no obstacle to authors owning the job of updating the baselines
for all ports when they land a change.
IMHO ports who don't run pixel tests would be better off deleting any png
results they have in the tree. Is there a reason Mac hasn't done that?
Don't you get lots of failures when you run pixel tests locally?
Yes, but I'd argue that it's better than losing the test coverage.
By the way, we can easily address this problem by always generating pixel
results for unexpectedly failing tests. Namely, we can force --pixel when
we're retrying tests.
Perhaps NRWT could produce txt and png results for all tests marked with
REBASELINE or similar in TestExpectations. That would avoid the need to
turn the bots red on each platform for at least one build cycle.
Or is that something we can live with?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't leave entries for rebaseline in TestExpectation files
On Thu, Mar 21, 2013 at 5:18 PM, Robert Hogan li...@roberthogan.net wrote: On Thursday, 21 March 2013, Ryosuke Niwa wrote: On Thu, Mar 21, 2013 at 1:31 AM, Robert Hogan li...@roberthogan.netwrote: On Thursday, 21 March 2013, Ryosuke Niwa wrote: I used to pull results from the bots where possible but creating inconsistency between png/text results is not good. It is unfortunate but it's much better than losing the complete test coverage. If that's the case then I'm happy to land whatever garden-o-matic pulls in or I can sweep from the bots, even if it means that png results for Mac, Qt, et al. go bad as a result. I guess we will always have ports whose bots do not run pixel tests so if those ports are happy to live with the downsides of doing that then there really is no obstacle to authors owning the job of updating the baselines for all ports when they land a change. IMHO ports who don't run pixel tests would be better off deleting any png results they have in the tree. Is there a reason Mac hasn't done that? Don't you get lots of failures when you run pixel tests locally? Yes, but I'd argue that it's better than losing the test coverage. By the way, we can easily address this problem by always generating pixel results for unexpectedly failing tests. Namely, we can force --pixel when we're retrying tests. Perhaps NRWT could produce txt and png results for all tests marked with REBASELINE or similar in TestExpectations. That would avoid the need to turn the bots red on each platform for at least one build cycle. I like this specific proposal. There's already a similar expectation planned, 'NeedsRebaseline'. https://bugs.webkit.org/show_bug.cgi?id=100415 Or is that something we can live with? ___ 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] PSA: EWS bots now upload results again
Fixed it in http://trac.webkit.org/changeset/146443. So yeah, don't add entries for rebaselines in platform/mac/TestExpectations please. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't leave entries for rebaseline in TestExpectation files
On Thu, Mar 21, 2013 at 10:54 AM, Žan Doberšek zandober...@gmail.comwrote: On Thu, Mar 21, 2013 at 5:18 PM, Robert Hogan li...@roberthogan.netwrote: On Thursday, 21 March 2013, Ryosuke Niwa wrote: On Thu, Mar 21, 2013 at 1:31 AM, Robert Hogan li...@roberthogan.netwrote: On Thursday, 21 March 2013, Ryosuke Niwa wrote: I used to pull results from the bots where possible but creating inconsistency between png/text results is not good. It is unfortunate but it's much better than losing the complete test coverage. If that's the case then I'm happy to land whatever garden-o-matic pulls in or I can sweep from the bots, even if it means that png results for Mac, Qt, et al. go bad as a result. I guess we will always have ports whose bots do not run pixel tests so if those ports are happy to live with the downsides of doing that then there really is no obstacle to authors owning the job of updating the baselines for all ports when they land a change. IMHO ports who don't run pixel tests would be better off deleting any png results they have in the tree. Is there a reason Mac hasn't done that? Don't you get lots of failures when you run pixel tests locally? Yes, but I'd argue that it's better than losing the test coverage. By the way, we can easily address this problem by always generating pixel results for unexpectedly failing tests. Namely, we can force --pixel when we're retrying tests. Perhaps NRWT could produce txt and png results for all tests marked with REBASELINE or similar in TestExpectations. That would avoid the need to turn the bots red on each platform for at least one build cycle. I like this specific proposal. There's already a similar expectation planned, 'NeedsRebaseline'. https://bugs.webkit.org/show_bug.cgi?id=100415 How do we know that new results is correct prior to running tests on each platform/port? There are cases where we regress tests on some ports while needing to rebaseline on other ports but all of that is unknown until we actually run tests on the bots. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't leave entries for rebaseline in TestExpectation files
dream I wish I could explicitly set an entry as being intended to be rebaselined, then notified (by email, by webkit-patch, something) when the tests covered by that entry have ran through all the bots with a url that shows the results so I can quickly validate them. In this magic world, if the results are correct, there'd simply be a button that would auto-generate a patch and toss it in the commit queue. /dream On Thu, Mar 21, 2013 at 11:16 AM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 10:54 AM, Žan Doberšek zandober...@gmail.comwrote: On Thu, Mar 21, 2013 at 5:18 PM, Robert Hogan li...@roberthogan.netwrote: On Thursday, 21 March 2013, Ryosuke Niwa wrote: On Thu, Mar 21, 2013 at 1:31 AM, Robert Hogan li...@roberthogan.netwrote: On Thursday, 21 March 2013, Ryosuke Niwa wrote: I used to pull results from the bots where possible but creating inconsistency between png/text results is not good. It is unfortunate but it's much better than losing the complete test coverage. If that's the case then I'm happy to land whatever garden-o-matic pulls in or I can sweep from the bots, even if it means that png results for Mac, Qt, et al. go bad as a result. I guess we will always have ports whose bots do not run pixel tests so if those ports are happy to live with the downsides of doing that then there really is no obstacle to authors owning the job of updating the baselines for all ports when they land a change. IMHO ports who don't run pixel tests would be better off deleting any png results they have in the tree. Is there a reason Mac hasn't done that? Don't you get lots of failures when you run pixel tests locally? Yes, but I'd argue that it's better than losing the test coverage. By the way, we can easily address this problem by always generating pixel results for unexpectedly failing tests. Namely, we can force --pixel when we're retrying tests. Perhaps NRWT could produce txt and png results for all tests marked with REBASELINE or similar in TestExpectations. That would avoid the need to turn the bots red on each platform for at least one build cycle. I like this specific proposal. There's already a similar expectation planned, 'NeedsRebaseline'. https://bugs.webkit.org/show_bug.cgi?id=100415 How do we know that new results is correct prior to running tests on each platform/port? There are cases where we regress tests on some ports while needing to rebaseline on other ports but all of that is unknown until we actually run tests on the bots. - 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] Please don't leave entries for rebaseline in TestExpectation files
On Thu, Mar 21, 2013 at 11:16 AM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 10:54 AM, Žan Doberšek zandober...@gmail.comwrote: On Thu, Mar 21, 2013 at 5:18 PM, Robert Hogan li...@roberthogan.netwrote: On Thursday, 21 March 2013, Ryosuke Niwa wrote: On Thu, Mar 21, 2013 at 1:31 AM, Robert Hogan li...@roberthogan.netwrote: On Thursday, 21 March 2013, Ryosuke Niwa wrote: I used to pull results from the bots where possible but creating inconsistency between png/text results is not good. It is unfortunate but it's much better than losing the complete test coverage. If that's the case then I'm happy to land whatever garden-o-matic pulls in or I can sweep from the bots, even if it means that png results for Mac, Qt, et al. go bad as a result. I guess we will always have ports whose bots do not run pixel tests so if those ports are happy to live with the downsides of doing that then there really is no obstacle to authors owning the job of updating the baselines for all ports when they land a change. IMHO ports who don't run pixel tests would be better off deleting any png results they have in the tree. Is there a reason Mac hasn't done that? Don't you get lots of failures when you run pixel tests locally? Yes, but I'd argue that it's better than losing the test coverage. By the way, we can easily address this problem by always generating pixel results for unexpectedly failing tests. Namely, we can force --pixel when we're retrying tests. Perhaps NRWT could produce txt and png results for all tests marked with REBASELINE or similar in TestExpectations. That would avoid the need to turn the bots red on each platform for at least one build cycle. I like this specific proposal. There's already a similar expectation planned, 'NeedsRebaseline'. https://bugs.webkit.org/show_bug.cgi?id=100415 How do we know that new results is correct prior to running tests on each platform/port? There are cases where we regress tests on some ports while needing to rebaseline on other ports but all of that is unknown until we actually run tests on the bots. If we're adding a token of this sort, it should be named something like NeedsTriaging. Saying that a test just needs a rebaseline is a pretense of knowledge. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Please don't land patches without rebaselining tests for at least one platform
Lately, I've encountering changesets that only add lines to TestExpectations and then never baseline tests for any platform. This makes it impossible to figure out what the expected results is for other platforms the patch author doesn't contribute to / care about. Furthermore, I don't know how reviewers are reviewing those patches given that they can't see new expected results on Bugzilla. Maybe they're reviewing patches in person? - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] WebSocket development
Hi all, I am starting to work on WebSocket development for WebKit and submitted a patch [1] for review some weeks ago. The thing is that only one reviewer in [2] is listed as working on WebSocket and he seems absent from WebKit development since October of last year. I tried to contact him through e-mail, no answer so far. I would like to know if anyone can review this and the other patches related to WebSocket that I plan to submit. I already tried to find someone on #webkit with no success. Thank you in advance. [1] https://bugs.webkit.org/show_bug.cgi?id=82714 [2] http://trac.webkit.org/wiki/WebKit%20Team Lamarque V. Souza Software Engineer (basyskom.com) Nokia Certified Qt Specialist ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: EWS bots now upload results again
I think to expect folks to use these results, we're going to need to give them nice tools, like: https://bugs.webkit.org/show_bug.cgi?id=92033 On Thu, Mar 21, 2013 at 10:55 AM, Ryosuke Niwa rn...@webkit.org wrote: Fixed it in http://trac.webkit.org/changeset/146443. So yeah, don't add entries for rebaselines in platform/mac/TestExpectations please. - 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] PSA: EWS bots now upload results again
On Thu, Mar 21, 2013 at 2:50 PM, Eric Seidel e...@webkit.org wrote: I think to expect folks to use these results, we're going to need to give them nice tools, like: https://bugs.webkit.org/show_bug.cgi?id=92033 I might work on that tonight if I decide to stay up 'til 4am again. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: EWS bots now upload results again
Thank you very much for making the uploads (and thus the flaky test reporter) work again! On Thu, Mar 21, 2013 at 2:52 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 2:50 PM, Eric Seidel e...@webkit.org wrote: I think to expect folks to use these results, we're going to need to give them nice tools, like: https://bugs.webkit.org/show_bug.cgi?id=92033 I might work on that tonight if I decide to stay up 'til 4am again. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebSocket development
+a...@webkit.org, tk...@chromium.org Hi Lamarque, I think they can review WebSocket related changes. On Thu, Mar 21, 2013 at 2:40 PM, Lamarque Souza lamarque.so...@basyskom.com wrote: ** Hi all, I am starting to work on WebSocket development for WebKit and submitted a patch [1] for review some weeks ago. The thing is that only one reviewer in [2] is listed as working on WebSocket and he seems absent from WebKit development since October of last year. I tried to contact him through e-mail, no answer so far. I would like to know if anyone can review this and the other patches related to WebSocket that I plan to submit. I already tried to find someone on #webkit with no success. Thank you in advance. [1] https://bugs.webkit.org/show_bug.cgi?id=82714 [2] http://trac.webkit.org/wiki/WebKit%20Team Lamarque V. Souza Software Engineer (basyskom.com) Nokia Certified Qt Specialist ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev -- Takashi Toyoshima Software Engineer, Google ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 12:49 PM, Ryosuke Niwa rn...@webkit.org wrote: Lately, I've encountering changesets that only add lines to TestExpectations and then never baseline tests for any platform. This (never rebaseline tests for any platform in that changeset) may not be possible depending on circumstances. For example, I do my dev work on MBP Retina, which produces different baselines than the platforms used for mac test bots. As a result, I sometimes have no choice but to land a changeset without a new baseline and then use garden-o-matic after-the-fact to land a new baseline. Or do you have an alternative in mind that would work in my case? Note that it really isn't practical for me to ask another dev to build my patch before landing in order to provide me a new baseline that i can add to the patch. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 4:02 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 12:49 PM, Ryosuke Niwa rn...@webkit.org wrote: Lately, I've encountering changesets that only add lines to TestExpectations and then never baseline tests for any platform. This (never rebaseline tests for any platform in that changeset) may not be possible depending on circumstances. For example, I do my dev work on MBP Retina, which produces different baselines than the platforms used for mac test bots. As a result, I sometimes have no choice but to land a changeset without a new baseline and then use garden-o-matic after-the-fact to land a new baseline. Then how are you verifying that your patch is correct? How are reviewers supposed to review such a patch? Uploading a rendering engine patch without first verifying that tests are still passing and new tests are generating results as expected sounds like a bad idea to me. Or do you have an alternative in mind that would work in my case? Note that it really isn't practical for me to ask another dev to build my patch before landing in order to provide me a new baseline that i can add to the patch. As I've announced on another thread, EWS now uploads actual results on Bugzilla so this shouldn't be an issue anymore. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 5:10 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:02 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 12:49 PM, Ryosuke Niwa rn...@webkit.org wrote: Lately, I've encountering changesets that only add lines to TestExpectations and then never baseline tests for any platform. This (never rebaseline tests for any platform in that changeset) may not be possible depending on circumstances. For example, I do my dev work on MBP Retina, which produces different baselines than the platforms used for mac test bots. As a result, I sometimes have no choice but to land a changeset without a new baseline and then use garden-o-matic after-the-fact to land a new baseline. Then how are you verifying that your patch is correct? How are reviewers supposed to review such a patch? Uploading a rendering engine patch without first verifying that tests are still passing and new tests are generating results as expected sounds like a bad idea to me. Of course I am verifying that tests are still passing and that new tests are generating results as expected. I do this by running NRWT without the patch, running it with the patch, then comparing results. This generally allows me to see new failures, which I manually review to determine the nature of the difference. If the difference is simply minor pixel positioning deltas (in text or image output), then I operate on the tentative hypothesis that a rebaseline is needed for the given test, unless I happen to be making a change that could be attributed to cause the delta. I'm also relying upon EWS to catch a regression before asking for a review. Or do you have an alternative in mind that would work in my case? Note that it really isn't practical for me to ask another dev to build my patch before landing in order to provide me a new baseline that i can add to the patch. As I've announced on another thread, EWS now uploads actual results on Bugzilla so this shouldn't be an issue anymore. But EWS is only testing on a couple of platform/ports yes? Presumably this will still impact qt/gtk/efl and perhaps others where EWS is just building and not testing? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 4:36 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 5:10 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:02 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 12:49 PM, Ryosuke Niwa rn...@webkit.org wrote: Lately, I've encountering changesets that only add lines to TestExpectations and then never baseline tests for any platform. This (never rebaseline tests for any platform in that changeset) may not be possible depending on circumstances. For example, I do my dev work on MBP Retina, which produces different baselines than the platforms used for mac test bots. As a result, I sometimes have no choice but to land a changeset without a new baseline and then use garden-o-matic after-the-fact to land a new baseline. Then how are you verifying that your patch is correct? How are reviewers supposed to review such a patch? Uploading a rendering engine patch without first verifying that tests are still passing and new tests are generating results as expected sounds like a bad idea to me. Of course I am verifying that tests are still passing and that new tests are generating results as expected. I do this by running NRWT without the patch, running it with the patch, then comparing results. This generally allows me to see new failures, which I manually review to determine the nature of the difference. If the difference is simply minor pixel positioning deltas (in text or image output), then I operate on the tentative hypothesis that a rebaseline is needed for the given test, unless I happen to be making a change that could be attributed to cause the delta. That sounds like a dangerous assumption to make. Due to the DPI differences, things like anti-aliasing will behave quite differently on Retina MBP. In general, I don't recommend people running and relying on layout tests on Retina MBP especially if you work on the rendering engine at this time. Or do you have an alternative in mind that would work in my case? Note that it really isn't practical for me to ask another dev to build my patch before landing in order to provide me a new baseline that i can add to the patch. As I've announced on another thread, EWS now uploads actual results on Bugzilla so this shouldn't be an issue anymore. But EWS is only testing on a couple of platform/ports yes? Presumably this will still impact qt/gtk/efl and perhaps others where EWS is just building and not testing? That's fine. I'm asking that you include rebaselines for at least one platform in the case that wasn't clear. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 5:40 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:36 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 5:10 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:02 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 12:49 PM, Ryosuke Niwa rn...@webkit.orgwrote: Lately, I've encountering changesets that only add lines to TestExpectations and then never baseline tests for any platform. This (never rebaseline tests for any platform in that changeset) may not be possible depending on circumstances. For example, I do my dev work on MBP Retina, which produces different baselines than the platforms used for mac test bots. As a result, I sometimes have no choice but to land a changeset without a new baseline and then use garden-o-matic after-the-fact to land a new baseline. Then how are you verifying that your patch is correct? How are reviewers supposed to review such a patch? Uploading a rendering engine patch without first verifying that tests are still passing and new tests are generating results as expected sounds like a bad idea to me. Of course I am verifying that tests are still passing and that new tests are generating results as expected. I do this by running NRWT without the patch, running it with the patch, then comparing results. This generally allows me to see new failures, which I manually review to determine the nature of the difference. If the difference is simply minor pixel positioning deltas (in text or image output), then I operate on the tentative hypothesis that a rebaseline is needed for the given test, unless I happen to be making a change that could be attributed to cause the delta. That sounds like a dangerous assumption to make. Due to the DPI differences, things like anti-aliasing will behave quite differently on Retina MBP. A hypothesis is not an assumption. It needs to be tested further. Be sure I am not making any unwarranted assumption. In general, I don't recommend people running and relying on layout tests on Retina MBP especially if you work on the rendering engine at this time. That's my platform, so I have to manage with it. Or do you have an alternative in mind that would work in my case? Note that it really isn't practical for me to ask another dev to build my patch before landing in order to provide me a new baseline that i can add to the patch. As I've announced on another thread, EWS now uploads actual results on Bugzilla so this shouldn't be an issue anymore. But EWS is only testing on a couple of platform/ports yes? Presumably this will still impact qt/gtk/efl and perhaps others where EWS is just building and not testing? That's fine. I'm asking that you include rebaselines for at least one platform in the case that wasn't clear. I will if possible, but I'm just saying it may not be possible on the initial landing in all cases. If it isn't then I expect to have to add rebaseline expectations and then take responsibility for following up on them ASAP. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 4:50 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 5:40 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:36 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 5:10 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:02 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 12:49 PM, Ryosuke Niwa rn...@webkit.orgwrote: Lately, I've encountering changesets that only add lines to TestExpectations and then never baseline tests for any platform. This (never rebaseline tests for any platform in that changeset) may not be possible depending on circumstances. For example, I do my dev work on MBP Retina, which produces different baselines than the platforms used for mac test bots. As a result, I sometimes have no choice but to land a changeset without a new baseline and then use garden-o-matic after-the-fact to land a new baseline. Then how are you verifying that your patch is correct? How are reviewers supposed to review such a patch? Uploading a rendering engine patch without first verifying that tests are still passing and new tests are generating results as expected sounds like a bad idea to me. Of course I am verifying that tests are still passing and that new tests are generating results as expected. I do this by running NRWT without the patch, running it with the patch, then comparing results. This generally allows me to see new failures, which I manually review to determine the nature of the difference. If the difference is simply minor pixel positioning deltas (in text or image output), then I operate on the tentative hypothesis that a rebaseline is needed for the given test, unless I happen to be making a change that could be attributed to cause the delta. That sounds like a dangerous assumption to make. Due to the DPI differences, things like anti-aliasing will behave quite differently on Retina MBP. A hypothesis is not an assumption. It needs to be tested further. Be sure I am not making any unwarranted assumption. I don't think operating based on a hypothesis is a good idea either. In general, I don't recommend people running and relying on layout tests on Retina MBP especially if you work on the rendering engine at this time. That's my platform, so I have to manage with it. I do have a Retina MBP too but I don't use it to work on the rendering engine precisely because of this issue. It's expected that every contributor has access to a machine where he/she can run layout tests. Retina MBP is not such a machine. As I've announced on another thread, EWS now uploads actual results on Bugzilla so this shouldn't be an issue anymore. But EWS is only testing on a couple of platform/ports yes? Presumably this will still impact qt/gtk/efl and perhaps others where EWS is just building and not testing? That's fine. I'm asking that you include rebaselines for at least one platform in the case that wasn't clear. I will if possible, but I'm just saying it may not be possible on the initial landing in all cases. If it isn't then I expect to have to add rebaseline expectations and then take responsibility for following up on them ASAP. What are cases where this is not possible? We need to fix that. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Fri, Mar 22, 2013 at 10:55 AM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:50 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 5:40 PM, Ryosuke Niwa rn...@webkit.org wrote: In general, I don't recommend people running and relying on layout tests on Retina MBP especially if you work on the rendering engine at this time. That's my platform, so I have to manage with it. I do have a Retina MBP too but I don't use it to work on the rendering engine precisely because of this issue. It's expected that every contributor has access to a machine where he/she can run layout tests. Retina MBP is not such a machine. Why is that the case? Why can't we start creating pixel test expectation for Retina MBPs? Silvia. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 5:04 PM, Silvia Pfeiffer silvi...@chromium.orgwrote: On Fri, Mar 22, 2013 at 10:55 AM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:50 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 5:40 PM, Ryosuke Niwa rn...@webkit.org wrote: In general, I don't recommend people running and relying on layout tests on Retina MBP especially if you work on the rendering engine at this time. That's my platform, so I have to manage with it. I do have a Retina MBP too but I don't use it to work on the rendering engine precisely because of this issue. It's expected that every contributor has access to a machine where he/she can run layout tests. Retina MBP is not such a machine. Why is that the case? Why can't we start creating pixel test expectation for Retina MBPs? Because run-webkit-tests doesn't support it. We don't even have a way of whether we're running on Retina MBP or not. If implemented correctly, retina will be a new dimension relative to platform and WK2. There will be a combinatorial explosion though because any given platform (e.g. Mountain Lion) could have combinations of WK1/WK2 and Retina/non-Retina. I have been discussing this matter with my colleagues but we haven't gotten around to implement it. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 5:55 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:50 PM, Glenn Adams gl...@skynav.com wrote: That's my platform, so I have to manage with it. I do have a Retina MBP too but I don't use it to work on the rendering engine precisely because of this issue. It's expected that every contributor has access to a machine where he/she can run layout tests. Retina MBP is not such a machine. Well, it's been working for me. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 5:10 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 5:55 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:50 PM, Glenn Adams gl...@skynav.com wrote: That's my platform, so I have to manage with it. I do have a Retina MBP too but I don't use it to work on the rendering engine precisely because of this issue. It's expected that every contributor has access to a machine where he/she can run layout tests. Retina MBP is not such a machine. Well, it's been working for me. The fact you appears to be contributing patches without appropriate rebaselines seems to indicate that it's not working for us. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 6:11 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 5:10 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 5:55 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:50 PM, Glenn Adams gl...@skynav.com wrote: That's my platform, so I have to manage with it. I do have a Retina MBP too but I don't use it to work on the rendering engine precisely because of this issue. It's expected that every contributor has access to a machine where he/she can run layout tests. Retina MBP is not such a machine. Well, it's been working for me. The fact you appears to be contributing patches without appropriate rebaselines seems to indicate that it's not working for us. Oh, please point out a case of without appropriate rebaseline. Please point out in the documentation where appropriate rebaseline is defined. I think you are making unwarranted assumptions here. If you can't define or understand a process where I can contribute using a MBP Retina, then I think you are imposing an arbitrary, unwarranted restriction on the community. I have been contributing successfully, ergo, it is working. Many are contributing WebCore layout and rendering patches using a wide variety of platforms, not all of which match your platform assumptions. It is not reasonable to claim they aren't contributing positively or that their contributions don't work. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Mar 21, 2013, at 5:38 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 6:11 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 5:10 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 5:55 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:50 PM, Glenn Adams gl...@skynav.com wrote: That's my platform, so I have to manage with it. I do have a Retina MBP too but I don't use it to work on the rendering engine precisely because of this issue. It's expected that every contributor has access to a machine where he/she can run layout tests. Retina MBP is not such a machine. Well, it's been working for me. The fact you appears to be contributing patches without appropriate rebaselines seems to indicate that it's not working for us. Oh, please point out a case of without appropriate rebaseline. Please point out in the documentation where appropriate rebaseline is defined. I think you are making unwarranted assumptions here. If you can't define or understand a process where I can contribute using a MBP Retina, then I think you are imposing an arbitrary, unwarranted restriction on the community. I have been contributing successfully, ergo, it is working. Many are contributing WebCore layout and rendering patches using a wide variety of platforms, not all of which match your platform assumptions. It is not reasonable to claim they aren't contributing positively or that their contributions don't work. We should definitely make it possible to contribute using a Retina system. Apple's flagship laptops offer Retina displays, and it would be crazy to rule them out as development machines. I'd imagine one day we may want the canonical Mac pixel results to be *only* retina. Perhaps one possibility is to make it possible to generate non-Retina pixel results on a Retina system. That seems eminently doable to me, unless there's something I am missing. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 6:05 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 21, 2013, at 5:38 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 6:11 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 5:10 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 5:55 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:50 PM, Glenn Adams gl...@skynav.com wrote: That's my platform, so I have to manage with it. I do have a Retina MBP too but I don't use it to work on the rendering engine precisely because of this issue. It's expected that every contributor has access to a machine where he/she can run layout tests. Retina MBP is not such a machine. Well, it's been working for me. The fact you appears to be contributing patches without appropriate rebaselines seems to indicate that it's not working for us. Oh, please point out a case of without appropriate rebaseline. Please point out in the documentation where appropriate rebaseline is defined. I think you are making unwarranted assumptions here. If you can't define or understand a process where I can contribute using a MBP Retina, then I think you are imposing an arbitrary, unwarranted restriction on the community. I have been contributing successfully, ergo, it is working. Many are contributing WebCore layout and rendering patches using a wide variety of platforms, not all of which match your platform assumptions. It is not reasonable to claim they aren't contributing positively or that their contributions don't work. We should definitely make it possible to contribute using a Retina system. Apple's flagship laptops offer Retina displays, and it would be crazy to rule them out as development machines. I'd imagine one day we may want the canonical Mac pixel results to be *only* retina. Yes, we should but it isn't today. Perhaps one possibility is to make it possible to generate non-Retina pixel results on a Retina system. That seems eminently doable to me, unless there's something I am missing. Yeah, Alexey and I were talking about this earlier. We need a some way to force CAGraphics, etc… to behave as if we're in non-Retina MBP. We definitely don't want to check in Retina pixel results. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Fri, Mar 22, 2013 at 12:30 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 6:05 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 21, 2013, at 5:38 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 6:11 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 5:10 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 5:55 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:50 PM, Glenn Adams gl...@skynav.com wrote: That's my platform, so I have to manage with it. I do have a Retina MBP too but I don't use it to work on the rendering engine precisely because of this issue. It's expected that every contributor has access to a machine where he/she can run layout tests. Retina MBP is not such a machine. Well, it's been working for me. The fact you appears to be contributing patches without appropriate rebaselines seems to indicate that it's not working for us. Oh, please point out a case of without appropriate rebaseline. Please point out in the documentation where appropriate rebaseline is defined. I think you are making unwarranted assumptions here. If you can't define or understand a process where I can contribute using a MBP Retina, then I think you are imposing an arbitrary, unwarranted restriction on the community. I have been contributing successfully, ergo, it is working. Many are contributing WebCore layout and rendering patches using a wide variety of platforms, not all of which match your platform assumptions. It is not reasonable to claim they aren't contributing positively or that their contributions don't work. We should definitely make it possible to contribute using a Retina system. Apple's flagship laptops offer Retina displays, and it would be crazy to rule them out as development machines. I'd imagine one day we may want the canonical Mac pixel results to be *only* retina. Yes, we should but it isn't today. Perhaps one possibility is to make it possible to generate non-Retina pixel results on a Retina system. That seems eminently doable to me, unless there's something I am missing. Yeah, Alexey and I were talking about this earlier. We need a some way to force CAGraphics, etc… to behave as if we're in non-Retina MBP. We definitely don't want to check in Retina pixel results. Where can I sign up to make this a higher priority. ;-) Developing on the Retina MBP is a real joy because of its speed and beautiful display - it is faster than the old Mac Pro I had. I was bummed to find out that I couldn't create pixel results on it nor properly run layout tests. Now I have a separate Linux machine for layout testing. Silvia. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't land patches without rebaselining tests for at least one platform
On Thu, Mar 21, 2013 at 6:39 PM, Silvia Pfeiffer silvi...@chromium.orgwrote: On Fri, Mar 22, 2013 at 12:30 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 6:05 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 21, 2013, at 5:38 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 6:11 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 5:10 PM, Glenn Adams gl...@skynav.com wrote: On Thu, Mar 21, 2013 at 5:55 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 4:50 PM, Glenn Adams gl...@skynav.com wrote: That's my platform, so I have to manage with it. I do have a Retina MBP too but I don't use it to work on the rendering engine precisely because of this issue. It's expected that every contributor has access to a machine where he/she can run layout tests. Retina MBP is not such a machine. Well, it's been working for me. The fact you appears to be contributing patches without appropriate rebaselines seems to indicate that it's not working for us. Oh, please point out a case of without appropriate rebaseline. Please point out in the documentation where appropriate rebaseline is defined. I think you are making unwarranted assumptions here. If you can't define or understand a process where I can contribute using a MBP Retina, then I think you are imposing an arbitrary, unwarranted restriction on the community. I have been contributing successfully, ergo, it is working. Many are contributing WebCore layout and rendering patches using a wide variety of platforms, not all of which match your platform assumptions. It is not reasonable to claim they aren't contributing positively or that their contributions don't work. We should definitely make it possible to contribute using a Retina system. Apple's flagship laptops offer Retina displays, and it would be crazy to rule them out as development machines. I'd imagine one day we may want the canonical Mac pixel results to be *only* retina. Yes, we should but it isn't today. Perhaps one possibility is to make it possible to generate non-Retina pixel results on a Retina system. That seems eminently doable to me, unless there's something I am missing. Yeah, Alexey and I were talking about this earlier. We need a some way to force CAGraphics, etc… to behave as if we're in non-Retina MBP. We definitely don't want to check in Retina pixel results. Where can I sign up to make this a higher priority. ;-) Post a patch on https://bugs.webkit.org/show_bug.cgi?id=93673. Developing on the Retina MBP is a real joy because of its speed and beautiful display - it is faster than the old Mac Pro I had. I was bummed to find out that I couldn't create pixel results on it nor properly run layout tests. Now I have a separate Linux machine for layout testing. Yes, I would love to be able to do that. Today, unfortunately, we can't :( - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebSocket development
Hi, I already tried to contact tkent on #websocket with no answer from him. Alexey commented on the bug entry I mentioned, that is good :-). Thanks for the answer. On March 21, 2013 at 11:37 PM Takashi Toyoshima toyos...@google.com wrote: +a...@webkit.org [mailto:a...@webkit.org] , tk...@chromium.org [mailto:tk...@chromium.org] Hi Lamarque, I think they can review WebSocket related changes. On Thu, Mar 21, 2013 at 2:40 PM, Lamarque Souza lamarque.so...@basyskom.com [mailto:lamarque.so...@basyskom.com] wrote: Hi all, I am starting to work on WebSocket development for WebKit and submitted a patch [1] for review some weeks ago. The thing is that only one reviewer in [2] is listed as working on WebSocket and he seems absent from WebKit development since October of last year. I tried to contact him through e-mail, no answer so far. I would like to know if anyone can review this and the other patches related to WebSocket that I plan to submit. I already tried to find someone on #webkit with no success. Thank you in advance. [1] https://bugs.webkit.org/show_bug.cgi?id=82714 [2] http://trac.webkit.org/wiki/WebKit%20Team Lamarque V. Souza Software Engineer (basyskom.com [http://basyskom.com] ) Nokia Certified Qt Specialist ___ webkit-dev mailing list webkit-dev@lists.webkit.org [mailto:webkit-dev@lists.webkit.org] https://lists.webkit.org/mailman/listinfo/webkit-dev -- Takashi Toyoshima Software Engineer, Google Lamarque V. Souza Software Engineer (basyskom.com) Nokia Certified Qt Specialist___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Where Paste from clipboard happens?
From reading the bug report, I'm guessing you can fix the bug by simply writing the correct text content to the clipboard. Just join the URLs with \n's in between and write the resulting text to the clipboard in BookmarkNodeData::WriteToClipboard(). Daniel On Thu, Mar 21, 2013 at 6:16 PM, Thiago Farina tfar...@chromium.org wrote: Hi, I was looking into crbug.com/106329, so I hacked up at chrome/browser/bookmarks/bookmark_node_data.cc:WriteToClipboard and changed it to write the URLs contained in |elements|. But now I need to read that information back from clipboard. But I have no idea where we do actually do this. Do we read from clipboard in //content/ or that is done in WebKit? If someone knows where that happens can you point me at to the source? Regards, -- Thiago ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
