> On 13 Sep 2018, at 08:50, Ryosuke Niwa <rn...@webkit.org> wrote:
> 
> 
> On Wed, Sep 12, 2018 at 3:09 PM Dean Jackson <d...@apple.com 
> <mailto:d...@apple.com>> wrote:
>> On 13 Sep 2018, at 08:05, Ali Juma <aj...@chromium.org 
>> <mailto:aj...@chromium.org>> wrote:
>> 
>> Is there a plan for how to handle web platform tests (where we can't add 
>> such a header)?
>> 
>> Currently, WebKitTestRunner enables all experimental features in tests 
>> (including those disabled by default), so adding an experimental feature 
>> (even one that's disabled by default) is a convenient way to get web 
>> platform test coverage for the feature. If WebKitTestRunner will no longer 
>> do that, we'll need some other way to keep these tests running.
> 
> I thought about this. I see three options:
> 
> 1. Continue to enable all experimental features in testing. The downside is 
> that we're testing something different to what we ship.
> 
> 2. Have the default value only apply to testing, not to shipping. For 
> Internal Features, instead of enabling them all, I had them revert to their 
> default value.
> 
> 3. Have some way to add the headers after importing the WPT test.
> 
> For now, I added headers to the WPT code, because there already were a bunch 
> of tests that had such headers.
> 
> Is that automated? We don't want get into a state where we'd have to manually 
> add those headers whenever we re-import tests.

It isn't.

I think maybe we should go for option 2 at the moment.

Or, ultimately, have a per-directory configuration file that could enable 
features.

Dean


_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to