[webkit-dev] An update on new-run-webkit-tests

Maciej Stachowiak mjs at apple.com
Wed Apr 6 21:01:11 PDT 2011

On Apr 6, 2011, at 7:39 PM, Dirk Pranke wrote:

> There are also a number of bugs currently listed as blocking that I
> don't think really qualify. Unless told otherwise, I'm plannning to
> remove the blocking flag from the following on Monday 4/11 (if they
> haven't been fixed first):
> 57640 [GTK] overlapping drag&drop tests fail on NRWT
> 55909 new-run-webkit-tests --run-singly option is busted
> 55163 new-run-webkit-tests: enable multiple processes by default on Chromium Win
> 47240 new-run-webkit-tests: getting an "error 2" back from ImageDiff
> 37426 new-run-webkit-tests should use the ServerProcess abstraction in
> chromium.py
> 37007 fast/tokenizer/doctype-search-reset.html fails when run out of
> order (new-run-webkit-tests)
> 35359 fast/repaint/renderer-destruction-by-invalidateSelection-crash.html
> fails intermittently
> 35266 new-run-webkit-tests --platform=mac-leopard timeout limit should
> match run-webkit-tests
> 35049 http/tests/security/cross-frame-access-put.html fails
> intermittently under new-run-webkit-tests
> 35006 fast/dom/global-constructors.html is failing based on previous tests
> Also, just because I don't think they should block a cutover, I do
> still think they should be fixed, so don't worry about that :)

I think the ones that represent tests newly failing or becoming flaky should be fixed before cutting over. We wouldn't want to lose test coverage when we do the switch, right?


More information about the webkit-dev mailing list