Update revert docs to align with current state #487
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: stbenjam The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
stbenjam
force-pushed
the
update-docs-about-reverts
branch
from
eed5a93 to
e7dd1e6
Compare
|
@stbenjam: all tests passed! Full PR test history. Your PR dashboard. 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-sigs/prow repository. I understand the commands that are listed here. |
|
|
||
| #### Who approves the revert for merge? | ||
| In order to ensure they are included in the conversation/resolution, we would like the team that delivered the original PR to /approve the reversion. However, if they are unavailable or unresponsive this may be escalated to the staff-engineering team to ensure we do not remain in a regressed state longer than necessary. | ||
| TRT has authority to apply the approved label to any revert in the OpenShift org, even for repositories they are not in OWNERS. They will notify the original author on Slack and in the revert PR, but to avoid staying regressed any longer than necessary, will not wait for acknowledgement. This also means if you're reverted, you don't need to respond until your normal working hours. |
There was a problem hiding this comment.
Maybe soften it a little by changing the order a bit:
TRT will attempt to notify the original author on Slack and in the revert PR. But to avoid staying regressed any longer than necessary, they have privledges to apply the approved label to any revert in the OpenShift org, even for repositories they are not in OWNERS. When the signal is clear regarding the source of a regression TRT has a mandate to restore payloads to healthy state as quickly as possible. This also means if you're reverted, you don't need to respond until your normal working hours.
| @@ -93,7 +99,6 @@ Given the timing of these events, it’s understandable that many teams aren’t | |||
|
|
|||
| Remember, anytime our payloads are regressed, the entire org is being impacted. While there may be a small cost to a single team to land an un-revert, it avoids a greater cost to the org as a whole. We want to get back to green as quickly as possible and avoid a slippery slope of a team wanting to try “one more fix” before we revert. Teams can also optionally run the acceptance checks on their original PR before merging it, to reduce the risk that the PR will have to be reverted. | |||
|
|
|||
|
|
|||
| #### What if these new checks are wrong? | |||
| We will need to carefully study the outcomes of this process to ensure that we are getting value from it (finding actual regressions) and not causing unnecessarily churn (raising revert PRs due to false positives when nothing has actually regressed, or the regression actually happened in an earlier payload but went undetected at the time). TRT will track data on how many times this reversion process gets triggered and the outcomes of each incident and then do a retrospective after the 4.10 release. | |||
There was a problem hiding this comment.
"will ... after 4.10" -- presumably happened, we probably don't need to repeat?
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci
bot
added
the
lifecycle/stale
No description provided.