Thanks for the heads-up. Some random thoughts on this: * For WPT tests, I would like a solution that does not discourage WebKit developers to contribute new tests to upstream WPT. It seems to me that such a risk exists for the proposal based on a header in the files.
* The per-directory or per-file configuration allows to verify the new feature for a particular set of tests. However, enabling new feature often affects other existing tests and may require further adjustments. It is actually good to enable new features for tests as early as possible since it sometimes helps WebKit developers to detect issues they had not initially expected. Right now it happens when the feature is set to DEFAULT_EXPERIMENTAL_FEATURES_ENABLED. IIUC with the current proposal that will now only happen when the feature is removed from the experimental category and hence already considered stable enough for shipping. * Similarly, I wonder what will be the behavior of experimental features in Safari Tech Preview? I think currently they can be on by defaut and hence allows to get early feedback from Web developers. Again they might be affected by a new feature, even when they don't know about it at all (and hence would not try to explicitly enable it). IIUC, with the current proposal, they will always be off by default. * A bit tangential, but I wonder whether we should have a policy to handle web-facing changes. Mozilla and Chromium developers typically send "Intent to implement/ship/remove etc" to their developer mailing lists so that people are aware of the web-facing changes and can discuss them. As previously mentioned, people might only notice a behavior change once the new feature is enabled. IIUC, with the current proposal that will again only happen once the feature is no longer considered experimental. -- Frédéric Wang - frederic-wang.fr _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
