kubernetes-sigs
Enhance `testfreeze` plugin to include Code Freeze
The testfreeze plugin mentions that a PR is being created during Test Freeze with a link to the automatic branch Fast Forward:
https://github.com/kubernetes-sigs/prow/blob/e3ae8cf22a59dce06665a4eec8ed70d14c276c77/pkg/plugins/testfreeze/testfreeze.go#L38
Side by side to Test Freeze (release branch creation happened) we also have Code Freeze:
We could extend the plugin to mention that we're in Code Freeze right now and a milestone maintainer from the corresponding SIG has to add that milestone. Also pinging the Release Managers or the whole SIG Release team to be aware of that PR.
Per documentation:
The Exception approval is the responsibility of the SIG or SIGs labeled in the pull request. The release team may intervene or deny the request only if it poses a risk to release quality, or could negatively impact the overall timeline.
Also: https://github.com/gracenng/sig-release/blob/master/release-team/README.md#milestone-maintainers
cc @kubernetes-sigs/release-engineering
It also refers to:
- https://github.com/kubernetes/sig-release/pull/2668
- https://github.com/kubernetes/website/pull/48833
We could extend the plugin to mention that we're in Code Freeze right now and a milestone maintainer from the corresponding SIG has to add that milestone.
According to https://kubernetes.io/releases/release/#milestone-maintainers, the milestone maintainer from the SIG must not just add the milestone. They have to get approval from the "Release Team Lead" first. Before we change the plugin, can we clarify how that approval is meant to be obtained and include that in the plugin's message?
Pointing contributors to https://github.com/orgs/kubernetes/teams/milestone-maintainers would be problematic:
- Contributors wouldn't know whom to pick (it's a long list, with no SIG affiliation).
- If they pick the wrong person, that person might set the milestone without consulting with SIG Release first. It has happened, which is why https://github.com/kubernetes/sig-release/pull/2668 was added.
@pohly good points! So the plugin comment should mention that:
- SIG Release approval is required first (by interacting with the PR)
- Approval from the corresponding SIG is required as well
In theory we could also think about the plugin validating those constraints and managing the milestone label, but that may be too much for now.
Approval from the corresponding SIG is required as well
That's not specific to code freeze, but doesn't hurt to call out. I would reorder the two points (first lgtm/approve from SIG, second milestone from SIG Release).
We still need to define how to alert SIG Release (cc <someone> and/or Slack on #sig-release?).
Posting requests in #sig-release is generally the way to go. Given that the Release Team sets up the new group of leadership every cycle, tagging @sig-release-leads in Slack specifically would alert the Release Team Lead and their supporting leadership.
/reopen
According to https://github.com/kubernetes-sigs/prow/pull/558#issuecomment-3610818559 the change should have been deployed two days ago in https://github.com/kubernetes/test-infra/pull/36014, but recent PRs still only mention "test freeze" and none of the new hints about getting the milestone (example).
@pohly: Reopened this issue.
In response to this:
/reopen
According to https://github.com/kubernetes-sigs/prow/pull/558#issuecomment-3610818559 the change should have been deployed two days ago in https://github.com/kubernetes/test-infra/pull/36014, but recent PRs still only mention "test freeze" and none of the new hints about getting the milestone (example).
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 guess hook needs to get updated which wasn't the case in https://github.com/kubernetes/test-infra/pull/36014. Let me investigate.
I guess we need to get this in https://github.com/kubernetes/k8s.io/pull/8744