[webkit-dev] When should we turn on new features?

[Adam Barth]

On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Feb 10, 2012, at 4:09 PM, Ryosuke Niwa wrote:
>
>> Hi all,
>>
>> In general, the decision of whether a given feature is enabled or not is made by each port. However, at last year's W3C TPAC, there were complaints from other participants about WebKit shipping half-baked implementations and breaking feature-detection.
>>
>> As an example, when WebKit enabled new types for form controls, we didn't initially have useful UIs. This resulted in breaking websites that relied on feature-detection to decide whether to use new types or fallback to JS-based fallback UI. Now those websites need to rely on navigator string. (I don't intend to name-call anyone or blame this instance in particular).
>>
>> So when is a Web-facing feature implemented in WebKit good enough to be enabled by any port? Should there be some set of criteria to be met?
>
> I think you raise a good point. Another point worth mentioning is that sometimes a feature can be complete and useful in one port, but half-baked in another (for example, fullscreen API was shipped in Safari and at the same time present but non-functional in Chrome).
>
> I think in the past, port owners have made clear that they want to own the final decisions on what features are enabled in their ports.
>
> But we as a community could do better, by having a shared recommendation of what features we think should be enabled in shipping releases. In some cases, this may not match the settings on trunk, as some features may be desirable to enable for experimental builds, but not in shipping product. For features that we recommended disabling, ideally we'd identify a reason. And in some cases, those might be port-specific issues.
>
> Would other port owners find such a list useful? Is anyone else willing to help maintain it? I think a good place to keep it would be in WebKit SVN, and we should treat it as if it was shared cross-platform code, which means anything in the list would require community consensus, not port-specific decisions. In some cases, we may have a hard time coming to agreement, in which case the default should probably be no recommendation either way.
>
> For features that we recommend for all ports and that do not have port specific issues, we might even consider removing the ENABLE flag.

One idea we've kicked around is to replace the binary on/off flags for
features (e.g., in features.gypi for the Chromium port) with something
like off/nightly/beta/stable.  That way folks can think about whether
they want to enable features for nightly, beta, or stable builds on a
given port.  This mechanism also gives the community a better sense
for the perceived maturity of each feature.

Adam