I filed https://bugs.webkit.org/show_bug.cgi?id=172068 to track the need
for some extra tooling for HTTP/WPT served tests.
We already gathered information about related requirements & workflows here.
Let's add more there!

Le ven. 12 mai 2017 à 19:50, <a...@webkit.org> a écrit :

>
> 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
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to