Add more milestone info to the release doc #4058
Conversation
k8s-ci-robot
added
cncf-cla: yes
k8s-ci-robot
added
area/developer-guide
jeefy
force-pushed
the
milestone-update
branch
from
9b40de9
to
2649c77
Compare
| - kubernetes/release | ||
| - kubernetes/sig-release | ||
| - kubernetes/website | ||
|
|
There was a problem hiding this comment.
I am curious - do all patches get milestoned these days? I'd love some clarifying language here!
There was a problem hiding this comment.
Once merged, a PR is milestoned to the milestone in which it merged.
There was a problem hiding this comment.
Also cherry-pick patches must have the milestone associated with the branch to which they are targeted. I've proposed some additional detail on this front via #4081 .
There was a problem hiding this comment.
Given the automation on release branches, users never are interacting with the milestone on release branches. If you make a PR against release-1.16 branch, it is milestoned as 1.16. I think it clutters the documentation to have separate treatment then. If it's worded as:
**On PRs against the master branch**, milestones are auto-applied so
this is less necessary.
**On PRS against anything not master** milestones are auto-applied so
this is less necessary.
Which then can be condensed to:
** On PRs**, milestones are auto-applied so
this is less necessary.
Which I don't think is the desire here.
I think what we actually have is:
- At creation time, PRs against the master branch need humans to hint at which milestone they might want the PR to target.
- Once merged, PRs against the master branch have milestones auto-applied so from that time onward
human management of that PR's milestone is less necessary. - On PRs against anything not master branch, milestones are auto-applied when the PR is created so
no human management of the milestone is less ever necessary.
|
this is good to have! |
|
/assign @justaugustus |
|
This looks good to me, but I'll hold off with the lgtm command to get additional review. |
There was a problem hiding this comment.
So here's the tricky thing...
Now that we have the milestone_applier plugin, it changes things a little.
Namely, any PR that merges within a certain timeframe will automatically get milestoned according to the rules here:
https://github.com/kubernetes/test-infra/blob/1a3702547e56328af9e764a3ac1ff8b1aa98a532/prow/plugins.yaml#L251-L265
So it isn't a strict requirement to have a milestone on the master branch, unless you definitely want the Release Team to watch the PR. This is only true of PRs, not issues.
On the patch release branches, the milestone is absolutely a requirement.
Ideally, I'd love it if everything was milestoned, but I'm just calling out the fact that not everything needs to be with the introduction of that plugin.
Let's get some more discussion going here before merging.
|
Let's reword, encompassing the following points (just trying to capture my best understanding of the situation)
TL;DR: milestone early, milestone often, and everyone will be happier. 😛 |
|
I wasn't going for using my somewhat casual language here 😅 but I think it's clear, and I like it. /lgtm |
k8s-ci-robot
added
the
lgtm
|
@justaugustus or @tpepper for approval? |
| - kubernetes/release | ||
| - kubernetes/sig-release | ||
| - kubernetes/website | ||
|
|
There was a problem hiding this comment.
Given the automation on release branches, users never are interacting with the milestone on release branches. If you make a PR against release-1.16 branch, it is milestoned as 1.16. I think it clutters the documentation to have separate treatment then. If it's worded as:
**On PRs against the master branch**, milestones are auto-applied so
this is less necessary.
**On PRS against anything not master** milestones are auto-applied so
this is less necessary.
Which then can be condensed to:
** On PRs**, milestones are auto-applied so
this is less necessary.
Which I don't think is the desire here.
I think what we actually have is:
- At creation time, PRs against the master branch need humans to hint at which milestone they might want the PR to target.
- Once merged, PRs against the master branch have milestones auto-applied so from that time onward
human management of that PR's milestone is less necessary. - On PRs against anything not master branch, milestones are auto-applied when the PR is created so
no human management of the milestone is less ever necessary.
|
@jeefy - PTAL? |
k8s-ci-robot
removed
the
lgtm
|
@guineveresaenger Thanks for the ping. Updated w/ @tpepper prose. :) |
|
Thanks y'all! |
|
@justaugustus: The provided milestone is not valid for this repository. Milestones in this repository: [ Use In 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. |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jeefy, justaugustus 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 |
k8s-ci-robot
added
the
approved
First pass at addressing kubernetes/sig-release#320.
Feedback and nits appreciated. :)