> 12 мая 2017 г., в 19:38, Brian Burg <bb...@apple.com> написал(а): > >> 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 >> >> <https://trac.webkit.org/export/216812/webkit/trunk/LayoutTests/fast/images/border.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. > > If the person works on WebKit, then it seems unreasonable that they would do > work without a checkout.
It is correct that people who work on WebKit usually have a checkout. So I was taking about people who don't work on WebKit. > If they don’t work on WebKit, then you could run wptserve on a machine > somewhere and link to that copy. We have several servers that exist solely to > host test content, it doesn’t seem like a big deal to make one of them update > regularly and relaunch wptserve to pick up test harness changes. Yes, there is a number of things one could do. Those things would work in some cases but not in others - I mentioned linking to a stable version that won't change, which is something that trac gives us for free, and it would be non-trivial to implement otherwise. In practice, the best approach would be to reduce the test to a minimum that doesn't use complex harnesses before ending it over. Everyone likes minimal test cases. - Alexey
_______________________________________________ webkit-dev mailing list email@example.com https://lists.webkit.org/mailman/listinfo/webkit-dev