Re: [webkit-dev] New status field required for feature flags
> On Jan 10, 2023, at 06:39, Michael Catanzaro wrote: > > Different default values for different ports is unavoidable; there are many > many other examples besides PDF.js where ports just need to be different. But > I think it's OK for the status field to be the same on all platforms. Just > set the status value to whatever works best for Apple. The status field could > control the *default* default value, which you can feature on > https://webkit.org/status/, but ports should still be able to override it if > needed. Sound good? > > By the way, while this seems like a good cleanup to me, I see there are > really a *lot* of statuses defined. I don't think I'd be able to understand > which one is correct to use for a feature unless I have that table explaining > what each one does in front of me. I wonder if they're all truly required. I’m adding some inline documentation to UnifiedWebPreferences.yaml in https://github.com/WebKit/WebKit/pull/8549, to help clarify things. Feedback appreciated! > On Jan 10, 2023, at 07:31, Jean-Yves Avenard > wrote: > > Hi. > > What status should be used for: > "Enabled by default on most platforms except those we’ve decided not to > support or if a local system dependency can’t be met but feature is still > ready for general use, but UI to toggle the feature remains to support > debugging, A/B testing." That should be an acceptable use for ‘stable’. With this in mind, Brent and I updated the definition of ’stable’ to relax it a bit: ON by default. Some platforms may deviate from default behavior due to # support or needed dependencies. > That defaultValue could be ignored in the future seems a regression and > doesn’t address some existing use cases. While we don’t have any enforcement of the defaults now (i.e. the the feature defaults are only advisory, and whatever is in defaultValue is used), I’d like to get us to a point where the defaults are widely used. The only time we should need to deviate is for platform-specific considerations like these. If and when we get there, I’ll make sure the defaultValue is *not* silently ignored by the code generator :) Elliott ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New status field required for feature flags
Hi. What status should be used for: "Enabled by default on most platforms except those we’ve decided not to support or if a local system dependency can’t be met but feature is still ready for general use, but UI to toggle the feature remains to support debugging, A/B testing." That defaultValue could be ignored in the future seems a regression and doesn’t address some existing use cases. Thanks Jean-Yves > On 10 Jan 2023, at 9:11 am, Elliott Williams via webkit-dev > wrote: > > Hi webkit-dev, > > Brent (CC’d) and I are rolling out changes to how we represent feature flags > in WebKit. As of https://commits.webkit.org/258448@main, the > WebPreferences*.yaml files have been merged to one feature list: > > Source/WTF/Preferences/UnifiedWebPreferences.yaml > > Instead of having separate lists of experimental features, internal debug > features, etc., each feature now has a `status` field. A feature’s status > determines which UIs it is visible in (if any), and in the future will > control its default value. Right now, these are the semantic meanings of the > features status: > > embedderAdjust WebKit behavior for embedding application needs. > unstableFeature in active development. Unfinished, no promise > it is usable or safe. > internalTools for debugging the WebKit engine. Not generally > useful to web developers. > developer Tools for web developers. > testableEnabled by default in test infrastructure, but not > ready to ship yet. Should be accessible for STP users who wish to activate > them for testing and feedback. > preview Enabled by default in Safari Technology Preview, but not > considered ready to ship yet. > stable Enabled by default and ready for general use, but UI to toggle > the feature remains to support debugging, A/B testing. > shippingEnabled by default and ready for general use, but no UI > to toggle. In general, will be removed 1 year after the change to shipping. > > When you’re adding or changing features, our source generator will force you > to pick one of these status. The “public-facing” statuses (developer, > testable, preview, stable) are visible from the various “experimental > features” call sites declared by WebKit, and the rest are exposed as > “internal debug features”. And I’m adding an additional WebPreferences API > which lists all features, so clients can avoid the > experimental/internal-debug dichotomy going forward. > > There’s one topic I’d like feedback on, which pertains to the non-Apple ports: > > Some features don’t seem to have the same “status” on all platforms. For > example, pdf.js has been enabled for GTK and WPE for some time now, and > should probably be considered `stable` on those platforms. But it’s off by > default on Apple platforms, where it should be no more than `testable`. How > do we resolve discrepancies like these? We could: > > - allow a feature’s status to be platform-conditional > - allow each port to decide whether a feature is on or off by default > (regardless of its status) > - do nothing, and require clients to change feature statuses at runtime in > order to modify default behavior > > I’d like to eventually use the committed feature list to power > https://webkit.org/status/, which makes me want to avoid having > platform-conditional statuses. It would also be nice for feature statuses to > be a global truth, helping us speak collectively about what web platform > features are supported. > > Elliott > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New status field required for feature flags
On Mon, Jan 9 2023 at 02:11:37 PM -0800, Elliott Williams via webkit-dev wrote: - allow each port to decide whether a feature is on or off by default (regardless of its status) Different default values for different ports is unavoidable; there are many many other examples besides PDF.js where ports just need to be different. But I think it's OK for the status field to be the same on all platforms. Just set the status value to whatever works best for Apple. The status field could control the *default* default value, which you can feature on https://webkit.org/status/, but ports should still be able to override it if needed. Sound good? By the way, while this seems like a good cleanup to me, I see there are really a *lot* of statuses defined. I don't think I'd be able to understand which one is correct to use for a feature unless I have that table explaining what each one does in front of me. I wonder if they're all truly required. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] New status field required for feature flags
Hi webkit-dev, Brent (CC’d) and I are rolling out changes to how we represent feature flags in WebKit. As of https://commits.webkit.org/258448@main, the WebPreferences*.yaml files have been merged to one feature list: Source/WTF/Preferences/UnifiedWebPreferences.yaml Instead of having separate lists of experimental features, internal debug features, etc., each feature now has a `status` field. A feature’s status determines which UIs it is visible in (if any), and in the future will control its default value. Right now, these are the semantic meanings of the features status: embedderAdjust WebKit behavior for embedding application needs. unstableFeature in active development. Unfinished, no promise it is usable or safe. internalTools for debugging the WebKit engine. Not generally useful to web developers. developer Tools for web developers. testableEnabled by default in test infrastructure, but not ready to ship yet. Should be accessible for STP users who wish to activate them for testing and feedback. preview Enabled by default in Safari Technology Preview, but not considered ready to ship yet. stable Enabled by default and ready for general use, but UI to toggle the feature remains to support debugging, A/B testing. shippingEnabled by default and ready for general use, but no UI to toggle. In general, will be removed 1 year after the change to shipping. When you’re adding or changing features, our source generator will force you to pick one of these status. The “public-facing” statuses (developer, testable, preview, stable) are visible from the various “experimental features” call sites declared by WebKit, and the rest are exposed as “internal debug features”. And I’m adding an additional WebPreferences API which lists all features, so clients can avoid the experimental/internal-debug dichotomy going forward. There’s one topic I’d like feedback on, which pertains to the non-Apple ports: Some features don’t seem to have the same “status” on all platforms. For example, pdf.js has been enabled for GTK and WPE for some time now, and should probably be considered `stable` on those platforms. But it’s off by default on Apple platforms, where it should be no more than `testable`. How do we resolve discrepancies like these? We could: - allow a feature’s status to be platform-conditional - allow each port to decide whether a feature is on or off by default (regardless of its status) - do nothing, and require clients to change feature statuses at runtime in order to modify default behavior I’d like to eventually use the committed feature list to power https://webkit.org/status/, which makes me want to avoid having platform-conditional statuses. It would also be nice for feature statuses to be a global truth, helping us speak collectively about what web platform features are supported. Elliott ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
