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
Committed r143702: <http://trac.webkit.org/changeset/143702>
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.
> I will update the file once the support is added to Chromium via Internals. Do you plan to do that?
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.
(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
Mr. Barth, can you please explain what is up?
> 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.
(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.
> 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.
(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).
> 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.