[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 #26 from Ryosuke Niwa <rniwa at webkit.org> ---
(In reply to Maciej Stachowiak from comment #25)
> (In reply to Ryosuke Niwa from comment #24)
> > (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 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.
> 
> Features in this category could potentially be crashy, or have serious
> security for perf issues. Or they could have nothing but stubs. It's
> probably good to use a name that sounds a bit scary. I'm not sure
> "prototype" or "exploratory" sufficiently convey that here there be dragons.
> It's possible there's a better word than "unstable" though.

Hm... maybe "untested" features? That conveys exactly what these things are.

> > > > 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.
> 
> I like distinguishing "option" flags from "feature" flags, but maybe we
> could try for something easy to type/read in config files. Maybe we don't
> need the word Enabled in all places, and perhaps these phrases could be all
> lowercase.

I don't think we necessarily need to type in these names. We could either put a new field in yaml like below or just put debugging options and feature flags in two different files. It's really confusing now that WebPreferences list both the list of features as well as things we only disable or enable for debugging purposes. That's a lot more important distinction than whether a given feature is being tested vs. experimental to me.

AsyncClipboardAPIEnabled:
  type: bool
  kind: feature
  state: stable
  humanReadableName: "Async Clipboard API"
  humanReadableDescription: "Enable the async clipboard API"
  defaultValue:
...

WebGL2Enabled:
  type: bool
  kind: feature
  state: experimental
  humanReadableName: "WebGL 2.0"
  humanReadableDescription: "WebGL 2 prototype"
  webcoreBinding: RuntimeEnabledFeatures
  condition: ENABLE(WEBGL2)
  defaultValue:
...

RequestIdleCallbackEnabled:
  type: bool
  kind: feature
  state: untested
  humanReadableName: "requestIdleCallback"
  humanReadableDescription: "Enable requestIdleCallback support"
  defaultValue:
...

TextAreasAreResizable:
  type: bool
  kind: internal.debug
  webcoreOnChange: setNeedsRecalcStyleInAllFrames
  defaultValue:
...

> For feature flag states that are features, not options, I wonder if we could
> get the WebKit feature status page to reflect them. It would be a bit more
> granular info than what we have now, where "Under Development" could be a
> wide range of conditions.

Yeah, I think that would be ideal. We've had a number of cases where the feature status page wasn't updated in time because the person who was working on it simply forgot about it.

This is sort of the thing I was talking about other day when I said we have too many random things we need to do / update when we work on a new feature. Anyway we can reduce the total number of random house keeping to do, the less likely that things will get out-of-date / out-of-sync.

-- 
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/9b68c1ce/attachment-0001.htm>