Re: [webkit-dev] Please don't leave entries for rebaseline in TestExpectation files
On Thu, Mar 21, 2013 at 1:57 AM, Ryosuke Niwa rn...@webkit.org 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. I've posted a patch on https://bugs.webkit.org/show_bug.cgi?id=112898 to implement this. Once that patch is landed, you can grab pixel results from any EWS bots and bots on build.webkit.org. - 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 Fri, Mar 22, 2013 at 1:12 AM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 1:57 AM, Ryosuke Niwa rn...@webkit.org 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. I've posted a patch on https://bugs.webkit.org/show_bug.cgi?id=112898 to implement this. Once that patch is landed, you can grab pixel results from any EWS bots and bots on build.webkit.org. Landed it in http://trac.webkit.org/changeset/146657. Once EWS bots catch up, we can start grabbing both text and pixel results off of Chromium and Mac EWS 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
On Fri, Mar 22, 2013 at 3:07 PM, Ryosuke Niwa rn...@webkit.org wrote: Landed it in http://trac.webkit.org/changeset/146657. Once EWS bots catch up, we can start grabbing both text and pixel results off of Chromium and Mac EWS bots. Thanks, this will be very useful! ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[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] 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
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 leave entries for rebaseline in TestExpectation files
Please don't add lines to TestExpectations saying that they just need rebaselines and then leave. 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. - 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
e.g. just in this afternoon, I was able to remove ~30 entries from platform/mac/TestExpectations. http://trac.webkit.org/changeset?new=146417%40trunk%2FLayoutTests%2Fplatform%2Fmac%2FTestExpectationsold=146296%40trunk%2FLayoutTests%2Fplatform%2Fmac%2FTestExpectations I bet there are a lot more entries in other platform/port's TestExpectations files. - 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
Hi, It looks EFL port has ~ 60 test cases which say to do rebaseline in TestExpectations file. I will remove them soon. Gyuyoung. On Thu, Mar 21, 2013 at 9:24 AM, Ryosuke Niwa rn...@webkit.org wrote: e.g. just in this afternoon, I was able to remove ~30 entries from platform/mac/TestExpectations. http://trac.webkit.org/changeset?new=146417%40trunk%2FLayoutTests%2Fplatform%2Fmac%2FTestExpectationsold=146296%40trunk%2FLayoutTests%2Fplatform%2Fmac%2FTestExpectations I bet there are a lot more entries in other platform/port's TestExpectations files. - 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
I remove test cases which need to do rebaseline on EFL TestExpectations file. http://trac.webkit.org/changeset/146432 The removed test cases are going to be done rebaseline. Gyuyoung. On Thu, Mar 21, 2013 at 9:59 AM, Gyuyoung Kim gyuyoung@webkit.orgwrote: Hi, It looks EFL port has ~ 60 test cases which say to do rebaseline in TestExpectations file. I will remove them soon. Gyuyoung. On Thu, Mar 21, 2013 at 9:24 AM, Ryosuke Niwa rn...@webkit.org wrote: e.g. just in this afternoon, I was able to remove ~30 entries from platform/mac/TestExpectations. http://trac.webkit.org/changeset?new=146417%40trunk%2FLayoutTests%2Fplatform%2Fmac%2FTestExpectationsold=146296%40trunk%2FLayoutTests%2Fplatform%2Fmac%2FTestExpectations I bet there are a lot more entries in other platform/port's TestExpectations files. - 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
