-
Notifications
You must be signed in to change notification settings - Fork 533
enhancements/update/update-blocker-lifecycle: Pivot to "update recommendations" #1093
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
enhancements/update/update-blocker-lifecycle: Pivot to "update recommendations" #1093
Conversation
Because he approved the original pull request creating the directory [1]. [1]: openshift#821 (comment)
Catching up with 36e98de (template: update guidance for specifying that no API approver is needed, 2022-04-10, openshift#1087).
af8037b to
9252596
Compare
…endations" Users are occasionally confused by the "blocked edges" wording, which is internal shorthand. The fact that update recommendations are tracked as a directed graph (hence "edges") isn't all that relevant for most users, so talk about "updates" instead of "edges". While we occasionally drop update recommendations to reduce the chances that users update into serious issues, from [1]: When an update recommendation is supported, it remains supported for the life of 4.10, even if the update recommendation is later dropped or made conditional. Updating is still possible, we just don't think it's a good idea (unless maybe you're elbow deep in a support case, and a support tech decides to recommend an update based on context that is not available to the update service). So replace "blocked" with "not recommended", to convey the "still possible" aspect. Also ask for some more specifics in the impact statement template, as we gear up to support conditional updates fff9d3c (enhancements/update/targeted-update-edge-blocking: Propose a new enhancement, 2020-08-07, openshift#821). [1]: https://docs.openshift.com/container-platform/4.10/updating/understanding-upgrade-channels-release.html#upgrade-version-paths_understanding-upgrade-channels-releases
9252596 to
18de135
Compare
|
/lgtm |
|
@sdodson: Overrode contexts on behalf of sdodson: ci/prow/markdownlint DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
@wking: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sdodson The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Users are occasionally confused by the "blocked edges" wording, which is internal shorthand.
The fact that update recommendations are tracked as a directed graph (hence "edges") isn't all that relevant for most users, so talk about "updates" instead of "edges".
While we occasionally drop update recommendations to reduce the chances that users update into serious issues, from docs:
Updating is still possible, we just don't think it's a good idea (unless maybe you're elbow deep in a support case, and a support tech decides to recommend an update based on context that is not available to the update service). So replace "blocked" with "not recommended", to convey the "still possible" aspect.
Also ask for some more specifics in the impact statement template, as we gear up to support conditional updates fff9d3c (#821). I haven't gone as far as "tell us what PromQL to use in our conditional recommendation", but I'm easing things in that direction.