[Webkit-unassigned] [Bug 125339] Enable running layout tests needing http server outside LayoutTests/http/tests

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Dec 16 13:12:20 PST 2013


https://bugs.webkit.org/show_bug.cgi?id=125339





--- Comment #9 from Dirk Pranke <dpranke at chromium.org>  2013-12-16 13:10:27 PST ---
I haven't done a detailed review of this yet. My initial reaction is that this adds more complexity to the setup than I'd really like; my initial leaning is that we should just serve *all* of LayoutTests/imported/w3c from http and call it good enough.

However, I think WebKit still only runs all of the http tests in a single thread, and even Blink only runs them in 25% of threads , so if we start running a lot of imported tests, this might be a bottle neck. It would be nice if there was some way other than manually tracking which directories did and did not actually require a web server, but I'm not sure if the w3c is going to be super excited to track that, as their basic model assumes tests are run off of a web server.

Perhaps the better thing to do is to focus on being able to run more tests in parallel off a web server without flakiness, I'm not sure.

At any rate, I'd like to do a more detailed review of this patch, but I don't want to block WebKit on this; if someone else (e.g., rniwa) wants to review/R+ it (eventually) and not wait on me, that's fine.

(I'm currently working again on the import process in Blink; where possible, I'd like to keep things as close to WebKit as possible, which is why I'm waffling on this at all).

Other things I'd note are that I think the map of which directories need or don't need the server should probably live at the top level under LayoutTests/ rather than in http/tests/conf . Also we should probably check for duplicates between LayoutTests/resources and LayoutTests/http/tests/resources (but this latter thing should be done in a separate patch).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list