-
Notifications
You must be signed in to change notification settings - Fork 597
Change Development phase to Experimental phase of a feature to better represent the state of a feature #495
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change Development phase to Experimental phase of a feature to better represent the state of a feature #495
Conversation
|
cc @dcberg @smawson @louiscryan @linsun @duderino @nrjpoddar I wasn't able to assign this to the TOC. |
|
I'd like to consider just combining dev and experimental into a single phase. They're basically the same modulo whether they show up in docs. Can we just rename development to experimental and get rid of development as a separate described phase? |
|
I don't think we currently describe development or experimental in user facing docs, so yes, we should just describe "experimental" and change all guides that say Development -> Experimental. |
|
I don't think we currently describe development or experimental in user facing docs, so yes, we should just describe "experimental" and change all guides that say Development -> Experimental. @jacob-delgado are you planning to update istio.io feature status after we reach consensus here for README? |
|
Do we need 2 pages with similar content https://github.com/istio/community/blob/944c44ca912deb97c669a1ddcb9bf92af51cc308/FEATURE-LIFECYCLE.md and https://istio.io/latest/about/feature-stages/#feature-phase-definitions |
|
If the "Recommended Use Cases" for Development/Experimental is "Don't" why are we exposing it to users? |
That is the intent. I'm just helping to facilitate this work at this point under the leadership from the TOC. |
Done. I've incorporated Development and Experimental into "Experimental." |
It was the same as it was Development. I've used the wording from Alpha as it fits into the concept better. Looking at Experimental, these are largely things done to get support to end users prior to the development of a proper API. Many users are weary of using things that are not properly documented on the site (e.g. environmental variables, cli args), but an experimental document gives people enough confidence to deploy it in their environment. However, they may have know the risk in doing so as backwards compatibility is not a given and likely will change as the feature is proven there is sufficient need for a proper API. |
|
Thanks for the updates, I like it. I'm happy to get this in and follow up with a discussion about whether we need this on istio.io and in github community or if we can just have one place point to another, but I think for now this is an improvement. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jacob-delgado I added few cosmetic changes but this is looking good. You might have to ping individual TOC members again to get their approval.
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
5 similar comments
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
We didn't have time during the TOC to talk about this. I'll add it to the agenda for next week. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jacob-delgado really nice work.
I added a few comments to help clarify the language and to use probability language (may) over can. There are also several other minor edit changes in this review recommended that don't affect the intent of the changes that improve clarity.
Cheers,
-steve
FEATURE-LIFECYCLE.md
Outdated
| <td>Alpha</td> | ||
| <td>Beta</td> | ||
| <td>Stable</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Purpose</td> | ||
| <td>Active development of a feature, not for use by end users directly.</td> | ||
| <td> Feature is under active development and user facing APIs will most likely change. Users should deploy experimental features with extreme caution, preferably in non-production environments as newer versions can require a migration effort.</td> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
most likely -> may
can -> may
newer versions -> experimental features (you are talking about the feature status and then switch context to the version...
FEATURE-LIFECYCLE.md
Outdated
| <td>Used to get feedback on a design or feature or see how a tentative design performs, etc. Targeted at developers and expert users.</td> | ||
| <td>Used to vet a solution in production without committing to it in the long term, to assess its viability, performance, usability, etc. Targeted at all users.</td> | ||
| <td>Dependable, production hardened</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Stability</td> | ||
| <td>Unknown</td> | ||
| <td>May be buggy. Using the feature may expose bugs. Users must opt-in to use feature.</td> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If Experimental and Alpha have the same stability, then I'd just copy line 28.
Another approach is to take a riff off what is there, which is May be buggy. This feature may have limited testing and field experience. Not active by default.
This other approach represents a development feature as really green, (not field proven..)
FEATURE-LIFECYCLE.md
Outdated
| <td>May be buggy. Using the feature may expose bugs. Not active by default.</td> | ||
| <td>Code is well tested. The feature is safe for production use.</td> | ||
| <td>Code is well tested and stable. Safe for widespread deployment in production.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Security</td> | ||
| <td>Unknown</td> | ||
| <td>Using the feature may have obvious security vulnerabilities. Discovered vulnerabilities will not necessarily be communicated broadly.</td> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will not necessarily -> may not
FEATURE-LIFECYCLE.md
Outdated
| <td>Using the feature may have obvious security vulnerabilities. Discovered vulnerabilities will not necessarily be communicated broadly.</td> | ||
| <td>Any discovered security vulnerabilities will be publicly disclosed and patched.</td> | ||
| <td>Any discovered security vulnerabilities will be publicly disclosed and patched.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Performance</td> | ||
| <td>Unknown</td> | ||
| <td>Performance characteristics are unknown. Enabling said features may adversely affect performance.</td> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove word said.
FEATURE-LIFECYCLE.md
Outdated
| <td>Performance requirements are assessed as part of design.</td> | ||
| <td>Performance and scalability are characterized, but may have caveats.</td> | ||
| <td>Perf (latency/scale) is quantified and documented, with guarantees against regression.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Support</td> | ||
| <td>None</td> | ||
| <td>No guarantees on backward compatibility. The feature may be dropped at any time without notice.</td> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dropped -> removed
FEATURE-LIFECYCLE.md
Outdated
| @@ -106,7 +106,9 @@ In addition to the basic alpha-level documentation, beta documentation includes | |||
| </tr> | |||
| <tr> | |||
| <td>Upgradeability</td> | |||
| <td>None</td> | |||
| <td>The schema and semantics of an experimental feature can change in newer versions without any guarantees of preserving backwards compatibility thereby requiring configuration changes during upgrades. | |||
| API versions can increment faster than the monthly release cadence and developers are not required to maintain multiple versions for backwards compatibility. | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can -> may
FEATURE-LIFECYCLE.md
Outdated
| <td>None</td> | ||
| <td>The schema and semantics of an experimental feature can change in newer versions without any guarantees of preserving backwards compatibility thereby requiring configuration changes during upgrades. | ||
| API versions can increment faster than the monthly release cadence and developers are not required to maintain multiple versions for backwards compatibility. | ||
| Developers are recommended to increment the API version when schema or semantics change in an incompatible way</td> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
recommended -> encouraged
FEATURE-LIFECYCLE.md
Outdated
| @@ -135,15 +137,16 @@ Test code coverage is >= 90%. | |||
| </tr> | |||
| <tr> | |||
| <td>Reliability</td> | |||
| <td>None</td> | |||
| <td>The user should not expect the feature to be reliable as it is relatively untested.</td> | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as it is -> may be
remove the world relatively
FEATURE-LIFECYCLE.md
Outdated
| <td>Because the feature is relatively new, and may lack complete end-to-end tests, enabling the feature via a flag might expose bugs which destabilize Istio (e.g. a bug in a control loop might rapidly create excessive numbers of objects, exhausting API storage).</td> | ||
| <td>Because the feature has e2e tests, enabling the feature should not create new bugs in unrelated features. | ||
| Because the feature is relatively new, it may have minor bugs.</td> | ||
| <td>High. The feature is well tested and stable and reliable for all uses.</td> | ||
| </tr> | ||
| <tr> | ||
| <td>Support</td> | ||
| <td>None</td> | ||
| <td>There is no commitment from the Istio community to progress or complete the feature and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
progress or complete-> improve, maintain, or complete
| @@ -153,7 +156,7 @@ Releases should simultaneously support two consecutive versions (e.g. v1beta1 an | |||
| </tr> | |||
| <tr> | |||
| <td>Recommended Use Cases</td> | |||
| <td>Don't</td> | |||
| <td>In short-lived development or testing environments, geared towards soliciting early feedback from users to shape development efforts.</td> | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is nice !
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
| @@ -135,15 +137,16 @@ Test code coverage is >= 90%. | |||
| </tr> | |||
| <tr> | |||
| <td>Reliability</td> | |||
| <td>None</td> | |||
| <td>The user should not expect the feature to be reliable may be untested.</td> | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI minor typo here, ... to be reliable and it may be untested.
* Use experimental as feature stage Pre-alpha/Development are deprecated in favor of Experimental (see istio/community#495). Update docs to reference this phase. * Add DNS proxying to experimental phase * Do not mix alpha and experimental * DNS Proxying is Alpha in 1.9; add to feature status page * Fix virtual machine install doc based on review * Fix linting issue
As discussed in the TOC on Friday Nov 6, 2020 there is misunderstanding revolving around Experimental, Development and Pre-Alpha.
The goal is to clarify what, if any of these terms should mean. After consensus is reached and this PR is merged I will update the documentation on the istio.io site to reflect this.
Examples: