[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 #24 from Ryosuke Niwa <rniwa at webkit.org> ---
(In reply to Sam Sneddon [:gsnedders] from comment #23)
> (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?

"unstable" to me conveys that it's simply crashy because "stability" often refers to how frequent a crash is encountered at least internally at Apple and elsewhere in the general software QA sense so I don't think we want to be using that specific term.

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

I disagree. That's one thing that separates WebKit from the rest of browser engine open source projects. We're very much insistent on using terminologies that make sense for humans even in our code so that we don't have code -> human-readable documentation. It has served us well, and we should continue to make our code self documentary.

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

The current policy is that any feature that could be complied on all platforms should be a runtime enabled feature unless it poses a new security, privacy, or perf cost that could not be rectified easily.

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

That is not sufficient in some cases because compile flags are needed for cases in which things just don't compile unless certain platform features / capabilities are available.

-- 
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/20210324/53cb6f94/attachment-0001.htm>