Milestone automation for PRs

[enisoc]

@spiffxp @marun @jberkus

This is a tracker to discuss extending some form of the milestone automation we have for issues to apply to pull requests.

The milestone has a different meaning on issues and PRs during code freeze:

• For issues, it means, "This is a release-blocking bug."
• For PRs, it means, "This code change is ok to make during freeze."

Note that these criteria can be independent: A PR might be allowed during freeze if it's approved for the milestone, even if it has no issue (/approve no-issue). Also, a PR associated with an issue that's approved for the milestone is not necessarily making a code change that's permissible during freeze.

For this reason, I propose applying milestone automation separately to issues and PRs, without trying to cross-reference the milestone status of issues linked from PRs. SIGs will need to separately approve the problem (issue) and the particular solution (PR) for the milestone.

The automation for PRs will help us do things like remove everything but release-blockers (priority/critical-urgent) from the milestone upon entering code freeze. It also would help communicate milestone requirements to PR authors during slush and freeze.

[spiffxp]

To make sure I understand, the GitHub queries for PR's suitable for merge would thus be:

status quo

  type:pr state:open repo:kubernetes/kubernetes 
  label:\"cncf-cla: yes\"
  label:lgtm 
  label:approved 
  -label:needs-ok-to-test
  -label:do-not-merge/hold 
  -label:do-not-merge/release-note-label-needed
  -label:do-not-merge/work-in-progress

code slush - all of the above, plus

  milestone:v1.9
  label:status/approved-for-milestone

code freeze - all of the above, plus

  label:priority/critical-urgent

Does this look right?

/cc @kubernetes/sig-testing-misc

[enisoc]

@spiffxp That looks like what I had in mind.

[enisoc]

Enabled in kubernetes/test-infra#5496.