Commit feae8952 authored by Xianzhu Wang's avatar Xianzhu Wang Committed by Commit Bot

Update RuntimeEnabledFeatures.md about status:"test"

This is a follow-up of crrev.com/c/2300832.

For more information, see https://groups.google.com/a/chromium.org/g/blink-dev/c/_COjLyfAEO0/m/1kC0sNuMAgAJ

Change-Id: I2fabe47f3ef855b5087f78f11d844cf432625924
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2299474
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: default avatarPhilip Rogers <pdr@chromium.org>
Reviewed-by: default avatarJason Chase <chasej@chromium.org>
Reviewed-by: default avatarStephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#789116}
parent 46d8bf63
...@@ -21,7 +21,7 @@ The status of the feature controls when it will be enabled in the Blink engine. ...@@ -21,7 +21,7 @@ The status of the feature controls when it will be enabled in the Blink engine.
| `experimental` | Yes | Yes | No | No | | `experimental` | Yes | Yes | No | No |
| `stable` | Yes | Yes | Yes | No | | `stable` | Yes | Yes | Yes | No |
\[1]: content_shell will not enable experimental/test features by default, the `--run-web-tests` flag used as part of running web tests enables this behaviour. \[1]: content_shell will not enable experimental/test features by default. The `--run-web-tests` flag used as part of running web tests enables this behaviour. The `--enable-blink-test-features` flag also enables this behavior in Chromium and content_shell's browser mode.
\[2]: Navigate to about:flags in the URL bar and turn on "Enable experimental web platform features" (formerly, "Enable experimental WebKit features") **or** run Chromium with `--enable-experimental-web-platform-features` (formerly, --enable-experimental-webkit-features). \[2]: Navigate to about:flags in the URL bar and turn on "Enable experimental web platform features" (formerly, "Enable experimental WebKit features") **or** run Chromium with `--enable-experimental-web-platform-features` (formerly, --enable-experimental-webkit-features).
Works in all Chromium channels: canary, dev, beta, and stable. Works in all Chromium channels: canary, dev, beta, and stable.
...@@ -60,15 +60,15 @@ will set the feature status to `experimental` on all platforms except on Androi ...@@ -60,15 +60,15 @@ will set the feature status to `experimental` on all platforms except on Androi
### Guidelines for Setting Feature Status ### Guidelines for Setting Feature Status
Any in-development feature can be added with no status, the only requirement is that code OWNERS are willing to have the code landed in the tree (as for any commit). Any in-development feature can be added with no status, the only requirement is that code OWNERS are willing to have the code landed in the tree (as for any commit).
* For a feature to be marked `status=test`, it must be in a sufficient state to permit internal testing. For example, enabling it should not be known to easily cause crashes, leak memory, or otherwise significantly effect the reliability of bots. Consideration should also be given to the potential for loss of test coverage of shipping behavior. For example, if a feature causes a new code path to be taken instead of an existing one, it is possible that some valuable test coverage and regression protection could be lost by setting a feature to `status=test`. Consider using a [virtual test suite] when it's important to keep testing both old and new code paths. * For a feature to be marked `status: "test"`, it must be in a sufficient state to permit internal testing. For example, enabling it should not be known to easily cause crashes, leak memory, or otherwise significantly effect the reliability of bots. Consideration should also be given to the potential for loss of test coverage of shipping behavior. For example, if a feature causes a new code path to be taken instead of an existing one, it is possible that some valuable test coverage and regression protection could be lost by setting a feature to `status: "test"`. Especially, using `status: "test"` for features that have substantially different code paths from the shipped product is strongly discouraged. Consider using a [virtual test suite] or setting up a [flag-specific] [trybot (example)] when it's important to keep testing both old and new code paths. [LayoutNG] and [BlinkGenPropertyTrees] are examples of features where we ensured test coverage of both new and old code paths until they were fully launched, without using `status: "test"`. See the linked document/bug for how we achieved that.
* For a feature to be marked `status=experimental`, it should be far enough along to permit testing by early adopter web developers. Many chromium enthusiasts run with `--enable-experimental-web-platform-features`, and so promoting a feature to experimental status can be a good way to get early warning of any stability or compatibility problems. If such problems are discovered (e.g. major websites being seriously broken when the feature is enabled), the feature should be demoted back to `status=test` to avoid creating undue problems for such users. It's notoriously difficult to diagnose a bug report from a user who neglects to mention that they have this flag enabled. Often a feature will be set to experimental status long before it's implementation is complete, and while there is still substantial churn on the API design. Features in this state are not expected to work completely, just do something of value which developers may want to provide feedback on. * For a feature to be marked `status: "experimental"`, it should be far enough along to permit testing by early adopter web developers. Many chromium enthusiasts run with `--enable-experimental-web-platform-features`, and so promoting a feature to experimental status can be a good way to get early warning of any stability or compatibility problems. If such problems are discovered (e.g. major websites being seriously broken when the feature is enabled), the feature should be demoted back to no status or `status: "test"` to avoid creating undue problems for such users. It's notoriously difficult to diagnose a bug report from a user who neglects to mention that they have this flag enabled. Often a feature will be set to experimental status long before it's implementation is complete, and while there is still substantial churn on the API design. Features in this state are not expected to work completely, just do something of value which developers may want to provide feedback on.
* For a feature to be marked `status=stable`, it must be complete and ready for use by all chrome users. Often this means it has gotten approval via the [blink launch process]. However, for features which are not web observable (e.g. a flag to track a large-scale code refactoring), this approval is not needed. In rare cases a feature may be tested on canary and dev channels by temporarily setting it to `status=stable`, with a comment pointing to a bug marked `Release-Block-Beta` tracking setting the feature back to `status=experimental` before the branch for beta. * For a feature to be marked `status: "stable"`, it must be complete and ready for use by all chrome users. Often this means it has gotten approval via the [blink launch process]. However, for features which are not web observable (e.g. a flag to track a large-scale code refactoring), this approval is not needed. In rare cases a feature may be tested on canary and dev channels by temporarily setting it to `status: "stable"`, with a comment pointing to a bug marked `Release-Block-Beta` tracking setting the feature back to `status: "experimental"` before the branch for beta.
When a feature has shipped and is no longer at risk of needing to be disabled, it's associated RuntimeEnableFeatures entry should be removed entirely. Permanent features should generally not have flags. When a feature has shipped and is no longer at risk of needing to be disabled, it's associated RuntimeEnableFeatures entry should be removed entirely. Permanent features should generally not have flags.
If a feature is not stable and no longer under active development, remove `status=test/experimental` on it (and consider deleting the code implementing the feature). If a feature is not stable and no longer under active development, remove `status: "test"/"experimental"` on it (and consider deleting the code implementing the feature).
### Runtime Enabled CSS Properties ### Runtime Enabled CSS Properties
...@@ -177,6 +177,10 @@ https://groups.google.com/a/chromium.org/d/msg/blink-dev/JBakhu5J6Qs/re2LkfEslTA ...@@ -177,6 +177,10 @@ https://groups.google.com/a/chromium.org/d/msg/blink-dev/JBakhu5J6Qs/re2LkfEslTA
[supportedPlatforms]: <https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/platform/runtime_enabled_features.json5#36> [supportedPlatforms]: <https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/platform/runtime_enabled_features.json5#36>
[cssProperties]: <https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/css/css_properties.json5> [cssProperties]: <https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/core/css/css_properties.json5>
[virtual test suite]: <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_tests.md#testing-runtime-flags> [virtual test suite]: <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_tests.md#testing-runtime-flags>
[flag-specific]: <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_tests.md#testing-runtime-flags>
[trybot (example)]: <https://chromium-review.googlesource.com/c/chromium/src/+/1850255>
[LayoutNG (launch plan)]: <https://docs.google.com/document/d/17t6HjA5X8T5xq1LlKoLEGTn_MioGCdEPpijpJeLalK0/edit#heading=h.guvbepjyp0oj>
[BlinkGenPropertyTrees]: <https://crbug.com/836884>
[blink launch process]: <https://www.chromium.org/blink/launching-features> [blink launch process]: <https://www.chromium.org/blink/launching-features>
[Blink extended attribute]: <https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/bindings/IDLExtendedAttributes.md> [Blink extended attribute]: <https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/bindings/IDLExtendedAttributes.md>
[make_runtime_features.py]: <https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/build/scripts/make_runtime_features.py> [make_runtime_features.py]: <https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/build/scripts/make_runtime_features.py>
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment