On Fri, May 12, 2017 at 7:31 PM, Alexey Proskuryakov <a...@webkit.org> wrote: > > 12 мая 2017 г., в 16:12, Sam Weinig <wei...@apple.com> написал(а): > > > > On May 12, 2017, at 2:49 PM, Alexey Proskuryakov <a...@webkit.org> wrote: > > > 12 мая 2017 г., в 14:38, Sam Weinig <wei...@apple.com> написал(а): > > I regret piling on here, as I think this thread has diverged from it’s > original purpose, but…I understand this frustration. That said, perhaps this > is something we can solve with some tooling. For instance, a > run-test-in-safari (as a parallel to run-safari) script could be made which > starts the server, and then loads the test with the right URL in your built > Safari (or MiniBrowser, or whatever). > > > That's still not good enough, as this means that I can't point someone else > to an instance of the test on trac.webkit.org to reproduce an issue. There > is of course be another place to point to when/if the test gets upstreamed, > but even that doesn't support stable links like trac does. > > That's not to mention that learning the name of this proposed script is no > easier than learning about run-webkit-httpd. > > - Alexey > > > I’m not sure what you mean by “good enough”. Good enough for what? What > are we debating here? > > > I think that I explained it very clearly, but let me try again. > > When there is a test failure that I need to communicate to others, I say > something "please open > <https://trac.webkit.org/export/216812/webkit/trunk/LayoutTests/fast/images/destroyed-image-load-event.html> > in Safari to reproduce". That's very easy to do, and makes it very easy for > others to work on the issue. > > If your test requires complex setup, like WPT does, then I may not have the > time to write up complicated steps to reproduce, or the person who gets the > bug may not have the time to follow them. Those people don't have a WebKit > checkout, so scripts won't help. This makes the test less effective, as > problems that it finds are less likely to be addressed.
Note that W3C's web-plaform-tests are hosted on http://w3c-test.org/tools/runner/index.html so you can could do the same thing. So this is about WPT server tests written in WebKit? But if it had to be a WPT server test, then the alternative would have been HTTP tests so the situation wouldn't have been different. If you're talking about tests that use testharness.js, then we would be using a relative path, so that should continue to work. - R. Niwa _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
