Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add more milestone info to the release doc #4058

Merged
merged 3 commits into from
Dec 6, 2019
Merged

Add more milestone info to the release doc #4058

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
2649c77
add more milestone info to release doc
jeefy Sep 5, 2019
31407f3
update language from guin's suggestion
jeefy Nov 11, 2019
4a7e6f9
update wording
jeefy Dec 6, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 27 additions & 0 deletions contributors/devel/sig-release/release.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -136,6 +136,33 @@ feature work for the given release has been defined in suitable
planning artifacts in conjunction with the Release Team's [enhancements
lead](https://git.k8s.io/sig-release/release-team/role-handbooks/enhancements/README.md).

After enhancement freeze, tracking milestones on PRs and Issues is
important. Items within the milestone are used as a punchdown list to
complete the release. *On issues*, milestones must be applied correctly, via
triage by the SIG, so that release team can track bugs and enhancements (any
enhancement related issue needs a milestone)

There is some automation in place to help automatically-assign milestones to
PRs. This automation only applies to the following repos:

* kubernetes/enhancements
* kubernetes/kubernetes
* kubernetes/release
* kubernetes/sig-release
* kubernetes/test-infra

**On PRs against the master branch**, milestones are auto-applied so
this is less necessary.

**On PRS against anything not master** the milestone
requirement is absolute and iron-clad necessary.

Any other effort that
should be tracked by the release team that doesn't fall under that
automation umbrella should be have a milestone applied.

*"Milestone early and milestone often. Everyone will be happier."*

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am curious - do all patches get milestoned these days? I'd love some clarifying language here!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once merged, a PR is milestoned to the milestone in which it merged.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 .

Copy link
Member

@tpepper tpepper Nov 15, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Implementation and bugfixing is ongoing across the cycle, but
culminates in a code freeze period:
* The **code freeze** starts in week ~10 and continues for ~2 weeks.
Expand Down