110566 2013-02-22 01:05:45 -0800 Layout Test fast/loader/stateobjects/state-url-sets-links-visited.html is timing out in chromium 2013-02-22 11:16:20 -0800 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 1 vsevik webkit-unassigned abarth benjamin koivisto oldest_to_newest 839348 0 vsevik 2013-02-22 01:05:45 -0800 The following layout test is failing in chromium fast/loader/stateobjects/state-url-sets-links-visited.html Caused by: http://trac.webkit.org/changeset/143678 http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2Floader%2Fstateobjects%2Fstate-url-sets-links-visited.html 839354 1 vsevik 2013-02-22 01:09:10 -0800 Committed r143702: <http://trac.webkit.org/changeset/143702> 839360 2 benjamin 2013-02-22 01:18:09 -0800 A timeout is a little unexpected. The max time before failing should have been around 1-2 second. Thank you for updating TestExpectations. I will update the file once the support is added to Chromium via Internals. 839599 3 abarth 2013-02-22 08:33:46 -0800 > I will update the file once the support is added to Chromium via Internals. Do you plan to do that? 839617 4 abarth 2013-02-22 08:49:00 -0800 Mr. Poulain doesn't seem to be around, so I'm rolling out the change. Hopefully he'll be able to re-land it cleanly and not break other ports. 839701 5 benjamin 2013-02-22 10:22:52 -0800 (In reply to comment #3) > > I will update the file once the support is added to Chromium via Internals. > > Do you plan to do that? I have had a patch ready for a while. I am fixing the related tests flakiness before landing: https://bugs.webkit.org/show_bug.cgi?id=109772 839709 6 benjamin 2013-02-22 10:30:18 -0800 Mr. Barth, can you please explain what is up? 839719 7 abarth 2013-02-22 10:37:13 -0800 > Mr. Barth, can you please explain what is up? You broke this test and you weren't around, so I rolled out your patch. Please feel free to re-land it in a way that doesn't break it. 839735 8 benjamin 2013-02-22 10:52:31 -0800 (In reply to comment #7) > > Mr. Barth, can you please explain what is up? > > You broke this test and you weren't around, so I rolled out your patch. Please feel free to re-land it in a way that doesn't break it. So I "broke" a failing test? Yes, yes, I guess rolling out without explanation is much more appropriate than just updating TestExpectations. It is also good I talked about this test with you on IRC yesterday. Thank you for your help. 839740 9 abarth 2013-02-22 10:58:46 -0800 > So I "broke" a failing test? Yes. You caused a test to change behavior in an unexpected way. That makes makes the bot turn red and is what we mean by breaking a test. > Yes, yes, I guess rolling out without explanation is much more appropriate than just updating TestExpectations. It is also good I talked about this test with you on IRC yesterday. Thank you for your help. The policy of this project is that you are not permitted to break other ports. I tried to contact you on the bug and on IRC, but you weren't around. I did the appropriate thing and reverted your patch. If you would like to change the policy for WebCore to match the "Apple can break other ports" policy for WebKit2, that's something that needs to be discussed on webkit-dev. I realize that I'm taking a hard line here, but I'm afraid that the WebKit2 "Apple is the only port that matters" policy will slow creep into WebCore. 839745 10 benjamin 2013-02-22 11:02:55 -0800 (In reply to comment #9) > I realize that I'm taking a hard line here, but I'm afraid that the WebKit2 "Apple is the only port that matters" policy will slow creep into WebCore. True, and I am well known for not helping the other ports too!!! I tend not to help Chromium like when you break WebKit1 yesterday (I was probably drunk back then). 839753 11 abarth 2013-02-22 11:16:20 -0800 > True, and I am well known for not helping the other ports too!!! I tend not to help Chromium like when you break WebKit1 yesterday (I was probably drunk back then). I appreciate your helping with that compile failure. It was obvious to me how to fix this test, I probably would have done that, but it wasn't obvious. Sweeping the problem under the rug in TestExpectations just leads to there being a lot of dirt under the rung. In any case, rollout patch out and rolling it back in isn't really a big deal. It's generally the safer course of action than trying to hot-fix an issue. For example, even after fixing the compile failure, there were several follow-on problems with Eric's patch yesterday. It's not clear to me that trying to hot-fix them led to the best outcome.