> 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

Reply via email to