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

[Ryosuke Niwa]

On Wed, Sep 12, 2018 at 11:02 PM Frédéric Wang <fwang at igalia.com> wrote:

> 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.
>

Why? Let's say I've been writing tests in fast/shadow-dom and I want to
export them to web-platform-tests/shadow-dom. The only thing I need to do
is to update some configuration file which WPT importer uses to add those
headers back when we import tests in that WPT directory.

* 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.
>

Yeah, I do share a similar concern. The idea that either the feature needs
to be experimental or ready-to-ship doesn't seem right. There are moments
in the time of developing a feature where we want to enable it for the
purpose of testing yet shouldn't be turned on by default for most ports.

But we don't need to impose a strict policy that we can't do this. It's
probably fine for a feature to be transiently enabled by default only in
WTR/DRT as the final validation step before the feature is turned on by
default.

* 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.
>

I think we don't want random features to be enabled by default in STP. We
really want STP's feature state to be matching what we're intending to
enable in Apple's macOS port.

* 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.
>

I think contributors who are adding a new Web-facing feature or enabling an
existing feature by default are expected to email webkit-dev first. I'd
rather not make it a formal policy though. All these bureaucracies add up.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20180912/b5c07ec0/attachment.html>