[webkit-dev] Experimental and (new) Internal feature flags

[Frédéric Wang]

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