From 895c8b0f360f84f3928d860f9c7e777b06665bf1 Mon Sep 17 00:00:00 2001 From: Joe Kutner Date: Tue, 7 Jul 2020 12:30:17 -0500 Subject: [PATCH 1/6] Experimental Features Signed-off-by: Joe Kutner --- text/0000-experimental-features.md | 78 ++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 text/0000-experimental-features.md diff --git a/text/0000-experimental-features.md b/text/0000-experimental-features.md new file mode 100644 index 000000000..f7c40f032 --- /dev/null +++ b/text/0000-experimental-features.md @@ -0,0 +1,78 @@ +# Meta +[meta]: #meta +- Name: Space and Process for Experimental Features +- Start Date: 2020-07-02 +- Author(s): [@jkutner](https://github.com/jkutner) +- RFC Pull Request: (leave blank) +- CNB Pull Request: (leave blank) +- CNB Issue: (leave blank) +- Supersedes: N/A + +# Summary +[summary]: #summary + +This is a proposal for allowing experimental features to enter Pack and Lifecycle without requiring a specification, core team review, or RFC. + +# Motivation +[motivation]: #motivation + +End-users and early adopters of CNB have real problems that need to be solved by the CNB project. Sometimes these problems prevent them from adopting CNB in their organizations. Our RFC process, specification guidelines, and governance structure provide a strong mechanism through which we can enact change and solve problems; but sometimes it's too heavy and inhibits experimentation. + +We need a way to introduce experiments before writing an RFC. Such a mechanism would allow us to deliver new capabilities faster, improve our means of collecting real end-user feedback, and improve the quality of our RFCs. + +# What it is +[what-it-is]: #what-it-is + +- *experimental feature* - any behavior or options that are likely to change before being added to the specification + +This proposal affects buildpack users, platform implementors, and project contributors who want to introduce experimental features into Pack or Lifecycle. Today, any significant change that impacts end-users is introduced through an RFC, which requires a successful vote by the core team before being introduced into the specification (or the Pack platform). + +We seek to change the current process such that experimental features do not require an RFC or specification. Instead, an experimental feature would only require approval by a simple majority of Platform Maintainers. + +# How it Works +[how-it-works]: #how-it-works + +Experimental features can be submitted as a PR or discussed in Github Issues on the relevant project. The team that maintains that project can decide whether or not to introduce the feature as long as it is behind an `--experimental` flag. + +# Drawbacks +[drawbacks]: #drawbacks + +- End users may become tied to features that eventually go away or significantly change + +# Alternatives +[alternatives]: #alternatives + +## Plugins + +A plugin system for Pack and/or Lifecycle would allow experimental features to be implemented completely outside of the CNB project. For example, a plugin could be installed to Pack with a command like: + +``` +$ pack install-plugin skele-gro +``` + +Then, a user can execute new commands provided by the plugin: + +``` +$ pack grow-bones +``` + +Or use new flags on existing commands: + +``` +$ pack build --with-bone-growth +``` + +Such a plugin mechanism would require a well defined plugin-interface, and versioning of that interface. This is a significantly larger project that the current proposal. However, the current proposal does not prevent a plugin system from being introduced later on. + +# Prior Art +[prior-art]: #prior-art + +- Rust's [Unstable features](https://doc.rust-lang.org/rustdoc/unstable-features.html) +- Java's [`-XX:+UnlockExperimentalVMOptions` flag](https://bugs.openjdk.java.net/browse/JDK-6618726) +- [oclif Plugins](https://oclif.io/docs/plugins) + +# Unresolved Questions +[unresolved-questions]: #unresolved-questions + +- How does an experimental features become a real feature (does it use the same flag/command minus the `--experimental` flag)? + From 41e695d85499a0dc8d1b9538fe7b6c7a665a9b1f Mon Sep 17 00:00:00 2001 From: Joe Kutner Date: Thu, 30 Jul 2020 07:56:06 -0500 Subject: [PATCH 2/6] Update text/0000-experimental-features.md Signed-off-by: Joe Kutner Co-authored-by: Javier Romero --- text/0000-experimental-features.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/text/0000-experimental-features.md b/text/0000-experimental-features.md index f7c40f032..31b4f27cc 100644 --- a/text/0000-experimental-features.md +++ b/text/0000-experimental-features.md @@ -32,7 +32,7 @@ We seek to change the current process such that experimental features do not req # How it Works [how-it-works]: #how-it-works -Experimental features can be submitted as a PR or discussed in Github Issues on the relevant project. The team that maintains that project can decide whether or not to introduce the feature as long as it is behind an `--experimental` flag. +Experimental features can be submitted as a PR or discussed in Github Issues on the relevant project. The team that maintains that project can decide whether or not to introduce the feature as long as it is behind a mechanism that enables or disables these features. # Drawbacks [drawbacks]: #drawbacks @@ -75,4 +75,3 @@ Such a plugin mechanism would require a well defined plugin-interface, and versi [unresolved-questions]: #unresolved-questions - How does an experimental features become a real feature (does it use the same flag/command minus the `--experimental` flag)? - From ac8f06094eb113edf89e00aac6b629cb6d1ab386 Mon Sep 17 00:00:00 2001 From: Joe Kutner Date: Thu, 30 Jul 2020 07:56:36 -0500 Subject: [PATCH 3/6] Update text/0000-experimental-features.md Signed-off-by: Joe Kutner Co-authored-by: David Freilich --- text/0000-experimental-features.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-experimental-features.md b/text/0000-experimental-features.md index 31b4f27cc..b558e77ef 100644 --- a/text/0000-experimental-features.md +++ b/text/0000-experimental-features.md @@ -27,7 +27,7 @@ We need a way to introduce experiments before writing an RFC. Such a mechanism w This proposal affects buildpack users, platform implementors, and project contributors who want to introduce experimental features into Pack or Lifecycle. Today, any significant change that impacts end-users is introduced through an RFC, which requires a successful vote by the core team before being introduced into the specification (or the Pack platform). -We seek to change the current process such that experimental features do not require an RFC or specification. Instead, an experimental feature would only require approval by a simple majority of Platform Maintainers. +We seek to change the current process such that experimental features do not require an RFC or specification. Instead, an experimental feature would only require approval by a simple majority of the relevant sub-teams maintainers. # How it Works [how-it-works]: #how-it-works From 87bc209b8412a55f8dea9860b0f6330c8e35a2f6 Mon Sep 17 00:00:00 2001 From: Joe Kutner Date: Thu, 30 Jul 2020 12:50:14 -0500 Subject: [PATCH 4/6] Remove references to lifecycle experimental Signed-off-by: Joe Kutner --- text/0000-experimental-features.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-experimental-features.md b/text/0000-experimental-features.md index b558e77ef..9536d4874 100644 --- a/text/0000-experimental-features.md +++ b/text/0000-experimental-features.md @@ -11,7 +11,7 @@ # Summary [summary]: #summary -This is a proposal for allowing experimental features to enter Pack and Lifecycle without requiring a specification, core team review, or RFC. +This is a proposal for allowing experimental features without requiring a specification, core team review, or RFC. # Motivation [motivation]: #motivation @@ -25,7 +25,7 @@ We need a way to introduce experiments before writing an RFC. Such a mechanism w - *experimental feature* - any behavior or options that are likely to change before being added to the specification -This proposal affects buildpack users, platform implementors, and project contributors who want to introduce experimental features into Pack or Lifecycle. Today, any significant change that impacts end-users is introduced through an RFC, which requires a successful vote by the core team before being introduced into the specification (or the Pack platform). +This proposal affects buildpack users, platform implementors, and project contributors who want to introduce experimental features. Today, any significant change that impacts end-users is introduced through an RFC, which requires a successful vote by the core team before being introduced into the specification (or the Pack platform). We seek to change the current process such that experimental features do not require an RFC or specification. Instead, an experimental feature would only require approval by a simple majority of the relevant sub-teams maintainers. From 87004b0af7f52dbb8634fc343b65557432e1a0df Mon Sep 17 00:00:00 2001 From: Terence Lee Date: Tue, 15 Sep 2020 10:38:26 -0700 Subject: [PATCH 5/6] describe tracking issue and experiment end Signed-off-by: Terence Lee --- text/0000-experimental-features.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/text/0000-experimental-features.md b/text/0000-experimental-features.md index 9536d4874..a4682fcf0 100644 --- a/text/0000-experimental-features.md +++ b/text/0000-experimental-features.md @@ -32,7 +32,9 @@ We seek to change the current process such that experimental features do not req # How it Works [how-it-works]: #how-it-works -Experimental features can be submitted as a PR or discussed in Github Issues on the relevant project. The team that maintains that project can decide whether or not to introduce the feature as long as it is behind a mechanism that enables or disables these features. +Experimental Features should have a tracking GitHub issue with an appropriate "experimental" label in the relevant repo. That issue should describe what it is, what it's trying to prove, and a proposed end date of the experiment. The end dates can be extended if needed. When the experiment has ended, it should be removed (if deemed a failure) or a RFC/implementation should be done depending on the feature. + +The sub-team that maintains the project can decide with a majority vote whether or not to introduce the feature as long as it is behind a mechanism that enables or disables these features. Where possible when a feature is used it should log a warning after it's used with a message that you used this experimental feature and a link to the tracking issue to collect feedback. # Drawbacks [drawbacks]: #drawbacks From f91946c61beaeec53207919ecb7a319e09f15b68 Mon Sep 17 00:00:00 2001 From: Terence Lee Date: Tue, 15 Sep 2020 15:42:25 -0700 Subject: [PATCH 6/6] incorporating feedback from @dfreilich Signed-off-by: Terence Lee --- text/0000-experimental-features.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/text/0000-experimental-features.md b/text/0000-experimental-features.md index a4682fcf0..7a9b91a06 100644 --- a/text/0000-experimental-features.md +++ b/text/0000-experimental-features.md @@ -32,10 +32,16 @@ We seek to change the current process such that experimental features do not req # How it Works [how-it-works]: #how-it-works -Experimental Features should have a tracking GitHub issue with an appropriate "experimental" label in the relevant repo. That issue should describe what it is, what it's trying to prove, and a proposed end date of the experiment. The end dates can be extended if needed. When the experiment has ended, it should be removed (if deemed a failure) or a RFC/implementation should be done depending on the feature. +In order to suggest an experimental feature, a tracking GitHub issue is created with the "experimental" label in the relevant repo. The issue should describe what it is, what it's trying to prove, and a proposed end date of the experiment. The end dates can be extended if needed. The sub-team that maintains the project can decide with a majority vote whether or not to introduce the feature as long as it is behind a mechanism that enables or disables these features. Where possible when a feature is used it should log a warning after it's used with a message that you used this experimental feature and a link to the tracking issue to collect feedback. +When the experiment has ended, there are two possible outcomes: +- if deemed not successful, the feature should be removed +- if deemed successful a RFC/implementation should be done depending on the feature + +If not much feedback is collected, that will be taken into account but ultimately up to the subteam in how to proceed. + # Drawbacks [drawbacks]: #drawbacks