[Webkit-unassigned] [Bug 222885] Formalize rules for what is an Experimental Feature

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=222885

--- Comment #23 from Sam Sneddon [:gsnedders] <gsnedders at apple.com> ---
(In reply to Ryosuke Niwa from comment #22)
> (In reply to Maciej Stachowiak from comment #21)
> > I like this proposal a lot!
> > 
> > One proposed friendly amendment: let's disallow missing status (build
> > failure if you try to add a feature with no status) and add meaningful
> > statuses for flags that are not test, experimental, or stable. Here's a few
> > I can think of:
> > * unstable - meant to be an actual feature, which would eventually evolve to
> > "test" status and beyond, but not yet functional and usable.
> > * internal debug - flags like "Disable Accelerated Compositing" that we
> > think browser devs might need to use to diagnose problems, but that we don't
> > think are reasonable useful for web developers
> > * developer debug - debugging flags that we think are reasonable for web
> > developers to try to diagnose problems (perhaps the WebRTC flags, currently
> > in their own submenu, would fall in this category)
> > 
> > Maybe pulling on this thread there'd be too many statuses to represent every
> > one, but missing status can be a mistake that's easy to make and hard to
> > spot (hard to notice lack of something), so I think it would be better to
> > have statuses that can apply to any kind of flag we'd like to have.
> 
> So the list of categories we're thinking is:
> "unstable" - feature in active/stale development
> "internal debug" - for WebKit engineers
> "developer debug" - toggling flags for web developers
> "tests" - enabled by default in DRT/WTR
> "experimental" - features enable by default in STP, etc... but not yet stable
> "stable" - enabled by default & ready for prime time

This seems pretty reasonable. I think we can definitely bikeshed the descriptions, and I think there are reasonable questions about whether we should have "experimental" enabled by default in any given application, but that's a discussion for each application rather than one that needs to have any effect on the categorisation within WebKit.

> I think "prototype" or "exploratory" might be better instead of "unstable".

I think we convey anything we don't have the confidence to be running tests against likely is risky to enable, so unstable seems suitable to me?

> I also feel like the distinction between "experimental" vs "developer debug"
> might be a bit confusing for web developers.
> 
> Maybe we need to explicitly call it some of the flags are for feature
> enablement and others are for debugging purposes so something like:
> "Internal Debug Options"
> "Developer Debug Options"
> "Exploratory Features"
> "Test Enabled Features"
> "Experimentally Enabled Features"
> "Stably Enabled Features"

It's probably not worth getting too hung up on exactly what string we use in the YAML file, and allow application embedding WebKit to choose how to present this information to users. If an application segregates the different categories (i.e., doesn't have the current Safari behaviour of putting everything in a single menu), I think the distinction between "experimental" and "developer debug" should be pretty clear?

All this said, probably relevant to any documentation of policy here is also the question of when we want a runtime flag versus a compile-time flag, especially for features in the "unstable" category. Documenting when we want early development to happen behind a compile-time flag instead of a run-time flag is probably relevant. And in extreme, one could imagine an implementation of the runtime flag system whereby the runtime-check is an inline function which returns the constant false for (e.g.) features in the "unstable" category to effectively largely disable them at compile-time.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210323/46b57c67/attachment.htm>