devel/sig-release: Markdown linting
Signed-off-by: Stephen Augustus <saugustus@vmware.com>
This commit is contained in:
Stephen Augustus
parent
42e7ac5557
commit
4964c404eb
|
|
@ -2,88 +2,92 @@
|
|||
|
||||
This document explains how cherry-picks are managed on release branches within
|
||||
the kubernetes/kubernetes repository.
|
||||
A common use case for this task is backporting PRs from master to release
|
||||
A common use case for this task is backporting PRs from master to release
|
||||
branches.
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [What Kind of PRs are Good for Cherry-picks](#what-kind-of-prs-are-good-for-cherry-picks)
|
||||
- [Initiate a Cherry-pick](#initiate-a-cherry-pick)
|
||||
- [Cherry-pick Review](#cherry-pick-review)
|
||||
- [Searching for Cherry-picks](#searching-for-cherry-picks)
|
||||
- [Troubleshooting Cherry-picks](#troubleshooting-cherry-picks)
|
||||
- [Cherry-picks for unsupported releases](#cherry-picks-for-unsupported-releases)
|
||||
|
||||
---
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [What Kind of PRs are Good for Cherry-Picks](#what-kind-of-prs-are-good-for-cherry-picks)
|
||||
- [Initiate a Cherry-pick](#initiate-a-cherry-pick)
|
||||
- [Cherry-pick Review](#cherry-pick-review)
|
||||
- [Searching for Cherry-picks](#searching-for-cherry-picks)
|
||||
- [Troubleshooting Cherry-picks](#troubleshooting-cherry-picks)
|
||||
- [Cherry-picks for unsupported releases](#cherry-picks-for-unsupported-releases)
|
||||
|
||||
## Prerequisites
|
||||
* [Contributor License Agreement](http://git.k8s.io/community/CLA.md) is
|
||||
|
||||
- [Contributor License Agreement](http://git.k8s.io/community/CLA.md) is
|
||||
considered implicit for all code within cherry-pick pull requests,
|
||||
**unless there is a large conflict**.
|
||||
* A pull request merged against the master branch.
|
||||
* [Release branch](https://git.k8s.io/release/docs/branching.md) exists.
|
||||
* The normal git and GitHub configured shell environment for pushing to your
|
||||
kubernetes `origin` fork on GitHub and making a pull request against a
|
||||
- A pull request merged against the master branch.
|
||||
- [Release branch](https://git.k8s.io/release/docs/branching.md) exists.
|
||||
- The normal git and GitHub configured shell environment for pushing to your
|
||||
kubernetes `origin` fork on GitHub and making a pull request against a
|
||||
configured remote `upstream` that tracks
|
||||
"https://github.com/kubernetes/kubernetes.git", including `GITHUB_USER`.
|
||||
* Have `hub` installed, which is most easily installed via `go get
|
||||
- Have `hub` installed, which is most easily installed via `go get
|
||||
github.com/github/hub` assuming you have a standard golang development
|
||||
environment.
|
||||
|
||||
|
||||
## What Kind of PRs are Good for Cherry-Picks
|
||||
|
||||
Compared to the normal master branch's merge volume across time,
|
||||
the release branches see one or two orders of magnitude less PRs.
|
||||
This is because there is an order or two of magnitude higher scrutiny.
|
||||
Again the emphasis is on critical bug fixes, eg:
|
||||
* Loss of data
|
||||
* Memory corruption
|
||||
* Panic, crash, hang
|
||||
* Security
|
||||
Again the emphasis is on critical bug fixes, e.g.,
|
||||
|
||||
- Loss of data
|
||||
- Memory corruption
|
||||
- Panic, crash, hang
|
||||
- Security
|
||||
|
||||
If you are proposing a cherry-pick and it is not a clear and obvious
|
||||
critical bug fix, please reconsider. If upon reflection you wish to
|
||||
continue, bolster your case by supplementing your PR with, eg:
|
||||
continue, bolster your case by supplementing your PR with e.g.,
|
||||
|
||||
* A GitHub issue detailing the problem
|
||||
- A GitHub issue detailing the problem
|
||||
|
||||
* Scope of the change
|
||||
- Scope of the change
|
||||
|
||||
* Risks of adding a change
|
||||
- Risks of adding a change
|
||||
|
||||
* Risks of associated regression
|
||||
- Risks of associated regression
|
||||
|
||||
* Testing performed, test cases added
|
||||
- Testing performed, test cases added
|
||||
|
||||
* Key stakeholder SIG reviewers/approvers attesting to their confidence in the
|
||||
change being a required backport
|
||||
|
||||
* If the change is in cloud-provider-specific platform code (which is in the
|
||||
process of being moved out of core Kubernetes), describe the customer impact,
|
||||
how the issue escaped initial testing, remediation taken to prevent similar
|
||||
future escapes, and why the change cannot be carried in your downstream
|
||||
fork of the Kubernetes project branches. It is critical that our full
|
||||
community is actively engaged on enhancements in the project. If a
|
||||
released feature was not enabled on a particular provider's platform, this
|
||||
is a community miss that needs to be resolved in the master branch for
|
||||
subsequent releases. Such enabling will not be backported to the patch
|
||||
release branches.
|
||||
- Key stakeholder SIG reviewers/approvers attesting to their confidence in the
|
||||
change being a required backport
|
||||
|
||||
- If the change is in cloud-provider-specific platform code (which is in the
|
||||
process of being moved out of core Kubernetes), describe the customer impact,
|
||||
how the issue escaped initial testing, remediation taken to prevent similar
|
||||
future escapes, and why the change cannot be carried in your downstream
|
||||
fork of the Kubernetes project branches. It is critical that our full
|
||||
community is actively engaged on enhancements in the project. If a
|
||||
released feature was not enabled on a particular provider's platform, this
|
||||
is a community miss that needs to be resolved in the master branch for
|
||||
subsequent releases. Such enabling will not be backported to the patch
|
||||
release branches.
|
||||
|
||||
## Initiate a Cherry-pick
|
||||
* Run the [cherry-pick
|
||||
script](https://git.k8s.io/kubernetes/hack/cherry_pick_pull.sh).
|
||||
This example applies a master branch PR #98765 to the remote branch
|
||||
`upstream/release-3.14`: `hack/cherry_pick_pull.sh upstream/release-3.14
|
||||
98765`
|
||||
* Be aware the cherry-pick script assumes you have a git remote called
|
||||
`upstream` that points at the Kubernetes github org.
|
||||
Please see our [recommended Git workflow](https://git.k8s.io/community/contributors/guide/github-workflow.md#workflow).
|
||||
* You will need to run the cherry-pick script separately for each patch release you want to cherry-pick to.
|
||||
|
||||
* Your cherry-pick PR will immediately get the `do-not-merge/cherry-pick-not-approved` label.
|
||||
[Normal rules apply for code merge](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/release.md#tldr),
|
||||
with some additional caveats outlined in the next section of this document.
|
||||
- Run the [cherry-pick script](https://git.k8s.io/kubernetes/hack/cherry_pick_pull.sh)
|
||||
This example applies a master branch PR #98765 to the remote branch
|
||||
`upstream/release-3.14`: `hack/cherry_pick_pull.sh upstream/release-3.14
|
||||
98765`
|
||||
|
||||
- Be aware the cherry-pick script assumes you have a git remote called
|
||||
`upstream` that points at the Kubernetes github org.
|
||||
|
||||
Please see our [recommended Git workflow](https://git.k8s.io/community/contributors/guide/github-workflow.md#workflow).
|
||||
|
||||
- You will need to run the cherry-pick script separately for each patch
|
||||
release you want to cherry-pick to.
|
||||
|
||||
- Your cherry-pick PR will immediately get the
|
||||
`do-not-merge/cherry-pick-not-approved` label.
|
||||
|
||||
[Normal rules apply for code merge](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/release.md#tldr),
|
||||
with some additional caveats outlined in the next section of this document.
|
||||
|
||||
## Cherry-pick Review
|
||||
|
||||
|
|
@ -101,46 +105,48 @@ or include in a comment the `/release-note-none` command.
|
|||
Cherry-pick pull requests are reviewed slightly differently than normal
|
||||
pull requests on the master branch in that they:
|
||||
|
||||
* Are by default expected to be `kind/bug` and `priority/critical-urgent`.
|
||||
- Are by default expected to be `kind/bug` and `priority/critical-urgent`.
|
||||
|
||||
* Milestones must be set on the PR reflecting the milestone for the target
|
||||
release branch (for example, milestone v1.11 for a cherry-pick onto branch
|
||||
release-1.11). This is normally done for you by automation.
|
||||
- Milestones must be set on the PR reflecting the milestone for the target
|
||||
release branch (for example, milestone v1.11 for a cherry-pick onto branch
|
||||
release-1.11). This is normally done for you by automation.
|
||||
|
||||
* Have one additional level of review in that they must be approved specifically
|
||||
for cherry-pick by branch approvers.
|
||||
- Have one additional level of review in that they must be approved
|
||||
specifically for cherry-pick by branch approvers.
|
||||
|
||||
The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager)
|
||||
will triage PRs targeted to the next .0 minor release branch up until the
|
||||
release, while the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager)
|
||||
will handle all cherry-picks to patch releases.
|
||||
The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager)
|
||||
will triage PRs targeted to the next .0 minor release branch up until the
|
||||
release, while the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager)
|
||||
will handle all cherry-picks to patch releases.
|
||||
|
||||
The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager)
|
||||
or the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager)
|
||||
are the final authority on branch approval by removing the `do-not-merge/cherry-pick-not-approved`
|
||||
label and triggering a merge into the target branch.
|
||||
The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager)
|
||||
or the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager)
|
||||
are the final authority on branch approval by removing the
|
||||
`do-not-merge/cherry-pick-not-approved` label and triggering a merge into the
|
||||
target branch.
|
||||
|
||||
The team scrubs through incoming cherry-picks on at least a weekly basis, daily during
|
||||
burndown ahead of a .0 release. Ahead of point releases, reminders of the
|
||||
cherry-pick deadline will be sent out to the community. Cherry-pick PRs are
|
||||
often metered into the release branches to give more deliberate CI signal across
|
||||
changes. For this reason your cherry-pick must be ready to merge ahead of
|
||||
the cherry-pick deadline, but those candidates may be merged during the days
|
||||
between the deadline and release.
|
||||
The team scrubs through incoming cherry-picks on at least a weekly basis,
|
||||
daily during burndown ahead of a .0 release. Ahead of point releases,
|
||||
reminders of the cherry-pick deadline will be sent out to the community.
|
||||
Cherry-pick PRs are often metered into the release branches to give more
|
||||
deliberate CI signal across changes. For this reason your cherry-pick must be
|
||||
ready to merge ahead of the cherry-pick deadline, but those candidates may be
|
||||
merged during the days between the deadline and release.
|
||||
|
||||
Open cherry-pick PRs which do not land in the current release will
|
||||
continue to be tracked by the team for consideration for inclusion in a next
|
||||
patch release.
|
||||
Open cherry-pick PRs which do not land in the current release will
|
||||
continue to be tracked by the team for consideration for inclusion in a next
|
||||
patch release.
|
||||
|
||||
If you are concerned about the status of your cherry-pick, err on the
|
||||
side of overcommunicating and reach out to the branch reviewer(s):
|
||||
If you are concerned about the status of your cherry-pick, err on the
|
||||
side of overcommunicating and reach out to the branch reviewer(s):
|
||||
|
||||
* During code freeze or after code thaw and ahead of a .0 release, to get attention on a cherry-pick by the current
|
||||
release team members see the [appropriate release folder](https://git.k8s.io/sig-release/releases)
|
||||
for the target release's team contact information. You may cc them with
|
||||
`@<githubusername>` on your cherry-pick PR.
|
||||
|
||||
* For prior branches, check the [patch release schedule](https://git.k8s.io/sig-release/releases/patch-releases.md), which includes contact information for the patch release team.
|
||||
- During code freeze or after code thaw and ahead of a .0 release, to get
|
||||
attention on a cherry-pick by the current release team members see the
|
||||
[appropriate release folder](https://git.k8s.io/sig-release/releases) for
|
||||
the target release's team contact information. You may cc them with
|
||||
`@<githubusername>` on your cherry-pick PR.
|
||||
- For prior branches, check the [patch release schedule](https://git.k8s.io/sig-release/releases/patch-releases.md),
|
||||
which includes contact information for the patch release team.
|
||||
|
||||
## Searching for Cherry-picks
|
||||
|
||||
|
|
@ -148,34 +154,42 @@ pull requests on the master branch in that they:
|
|||
|
||||
- [A sample search on kubernetes/kubernetes pull requests that are labeled as `do-not-merge/cherry-pick-not-approved`](https://github.com/kubernetes/kubernetes/pulls?q=is%3Aopen+is%3Apr+label%3Ado-not-merge%2Fcherry-pick-not-approved)
|
||||
|
||||
|
||||
## Troubleshooting Cherry-picks
|
||||
|
||||
Contributors may encounter some of the following difficulties when initiating a cherry-pick.
|
||||
Contributors may encounter some of the following difficulties when initiating a
|
||||
cherry-pick.
|
||||
|
||||
- A cherry-pick PR does not apply cleanly against an old release branch.
|
||||
In that case, you will need to manually fix conflicts.
|
||||
- A cherry-pick PR does not apply cleanly against an old release branch. In
|
||||
that case, you will need to manually fix conflicts.
|
||||
|
||||
- The cherry-pick PR includes code that does not pass CI tests.
|
||||
In such a case you will have to fetch the auto-generated branch from your fork, amend the problematic commit and force push to the auto-generated branch.
|
||||
Alternatively, you can create a new PR, which is noisier.
|
||||
- The cherry-pick PR includes code that does not pass CI tests. In such a case
|
||||
you will have to fetch the auto-generated branch from your fork, amend the
|
||||
problematic commit and force push to the auto-generated branch.
|
||||
Alternatively, you can create a new PR, which is noisier.
|
||||
|
||||
## Cherry-picks for unsupported releases
|
||||
|
||||
The release team only supports & patches `n-3` releases (`n` being the latest release of Kubernetes). In January of 2019 the community discovered a regression, that was introduced in a post-release patch, but was currently no longer supported.
|
||||
The release team only supports & patches `n-3` releases (`n` being the latest
|
||||
release of Kubernetes). In January of 2019 the community discovered a
|
||||
regression, that was introduced in a post-release patch, but was currently no
|
||||
longer supported.
|
||||
|
||||
As discussed in a sig-release meeting on 2019-01-15, a fix was backported to the non supported version.
|
||||
As discussed in a sig-release meeting on 2019-01-15, a fix was backported to
|
||||
the non supported version.
|
||||
|
||||
Reference PR: [#72860](https://github.com/kubernetes/kubernetes/pull/72860#issuecomment-454072746)
|
||||
|
||||
The specific criteria driving the decision was:
|
||||
|
||||
- CI was still available for the version
|
||||
- The regression was introduced as a patch (and not part of the official release)
|
||||
- The regression was introduced as a patch (and not part of the official
|
||||
release)
|
||||
- The issue being fixed is of sufficient **[severity & impact](#what-kind-of-prs-are-good-for-cherry-picks)**
|
||||
- The fix is well understood and contained (doesn’t introduce risk of additional regressions)
|
||||
- The fix is well understood and contained (doesn’t introduce risk of
|
||||
additional regressions)
|
||||
|
||||
A note about the specific case in [#72860](https://github.com/kubernetes/kubernetes/pull/72860#issuecomment-454072746):
|
||||
|
||||
- The patch was exceedingly tiny and very unlikely to introduce new problems
|
||||
- Luckily, it was caught shortly after the release was supposed to be unsupported
|
||||
- Luckily, it was caught shortly after the release was supposed to be
|
||||
unsupported
|
||||
|
|
|
|||
|
|
@ -32,9 +32,9 @@ You can also use the gsutil tool to explore the Google Cloud Storage release
|
|||
buckets. Here are some examples:
|
||||
|
||||
```sh
|
||||
gsutil cat gs://kubernetes-release-dev/ci/latest.txt # output the latest ci version number
|
||||
gsutil ls gs://kubernetes-release-dev/ci/v0.20.0-29-g29a55cc/ # list the contents of a ci release
|
||||
gsutil ls gs://kubernetes-release/release # list all official releases and rcs
|
||||
gsutil cat gs://kubernetes-release-dev/ci/latest.txt # output the latest ci version number
|
||||
gsutil ls gs://kubernetes-release-dev/ci/v0.20.0-29-g29a55cc/ # list the contents of a ci release
|
||||
gsutil ls gs://kubernetes-release/release # list all official releases and rcs
|
||||
```
|
||||
|
||||
## Install `gsutil`
|
||||
|
|
@ -42,6 +42,6 @@ gsutil ls gs://kubernetes-release/release # list all official re
|
|||
Example installation:
|
||||
|
||||
```console
|
||||
$ curl -sSL https://storage.googleapis.com/pub/gsutil.tar.gz | sudo tar -xz -C /usr/local/src
|
||||
$ sudo ln -s /usr/local/src/gsutil/gsutil /usr/bin/gsutil
|
||||
curl -sSL https://storage.googleapis.com/pub/gsutil.tar.gz | sudo tar -xz -C /usr/local/src
|
||||
sudo ln -s /usr/local/src/gsutil/gsutil /usr/bin/gsutil
|
||||
```
|
||||
|
|
|
|||
|
|
@ -4,116 +4,109 @@ This document is focused on Kubernetes developers and contributors
|
|||
who need to create a feature, issue, or pull request which targets a specific
|
||||
release milestone.
|
||||
|
||||
- [TL;DR](#tldr)
|
||||
- [Definitions](#definitions)
|
||||
- [The Release Cycle](#the-release-cycle)
|
||||
- [Removal Of Items From The Milestone](#removal-of-items-from-the-milestone)
|
||||
- [Adding An Item To The Milestone](#adding-an-item-to-the-milestone)
|
||||
- [Milestone Maintainers](#milestone-maintainers)
|
||||
- [Feature additions](#feature-additions)
|
||||
- [Issue additions](#issue-additions)
|
||||
- [PR Additions](#pr-additions)
|
||||
- [Other Required Labels](#other-required-labels)
|
||||
- [SIG Owner Label](#sig-owner-label)
|
||||
- [Priority Label](#priority-label)
|
||||
- [Issue Kind Label](#issue-kind-label)
|
||||
- [TL;DR](#tldr)
|
||||
- [Normal Dev (Weeks 1-8)](#normal-dev-weeks-1-8)
|
||||
- [Code Freeze (Weeks 9-11)](#code-freeze-weeks-9-11)
|
||||
- [Post-Release (Weeks 11+)](#post-release-weeks-11)
|
||||
- [Definitions](#definitions)
|
||||
- [The Release Cycle](#the-release-cycle)
|
||||
- [Removal Of Items From The Milestone](#removal-of-items-from-the-milestone)
|
||||
- [Adding An Item To The Milestone](#adding-an-item-to-the-milestone)
|
||||
- [Milestone Maintainers](#milestone-maintainers)
|
||||
- [Feature additions](#feature-additions)
|
||||
- [Issue additions](#issue-additions)
|
||||
- [PR Additions](#pr-additions)
|
||||
- [Other Required Labels](#other-required-labels)
|
||||
- [SIG Owner Label](#sig-owner-label)
|
||||
- [Priority Label](#priority-label)
|
||||
- [Issue/PR Kind Label](#issuepr-kind-label)
|
||||
|
||||
The process for shepherding features, issues, and pull requests
|
||||
into a Kubernetes release spans multiple stakeholders:
|
||||
* the feature, issue, or pull request owner
|
||||
* SIG leadership
|
||||
* the release team
|
||||
|
||||
- the feature, issue, or pull request owner
|
||||
- SIG leadership
|
||||
- the release team
|
||||
|
||||
Information on workflows and interactions are described below.
|
||||
|
||||
As the owner of a feature, issue, or pull request (PR), it is your
|
||||
responsibility to ensure release milestone requirements are met.
|
||||
Automation and the release team will be in contact with you if
|
||||
updates are required, but inaction can result in your work being
|
||||
removed from the milestone. Additional requirements exist when the
|
||||
target milestone is a prior release (see [cherry pick
|
||||
process](cherry-picks.md) for more information).
|
||||
responsibility to ensure release milestone requirements are met. Automation and
|
||||
the release team will be in contact with you if updates are required, but
|
||||
inaction can result in your work being removed from the milestone. Additional
|
||||
requirements exist when the target milestone is a prior release (see
|
||||
[cherry pick process](cherry-picks.md) for more information).
|
||||
|
||||
## TL;DR
|
||||
|
||||
If you want your PR to get merged, it needs the following required labels and milestones, represented here by the Prow /commands it would take to add them:
|
||||
<table>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td>Normal Dev</td>
|
||||
<td>Code Freeze</td>
|
||||
<td>Post-Release</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td></td>
|
||||
<td>Weeks 1-8</td>
|
||||
<td>Weeks 9-11</td>
|
||||
<td>Weeks 11+</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Required Labels</td>
|
||||
<td>
|
||||
<ul>
|
||||
<!--Weeks 1-8-->
|
||||
<li>/sig {name}</li>
|
||||
<li>/kind {type}</li>
|
||||
<li>/lgtm</li>
|
||||
<li>/approved</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td>
|
||||
<ul>
|
||||
<!--Weeks 9-11-->
|
||||
<li>/milestone {v1.y}</li>
|
||||
<li>/sig {name}</li>
|
||||
<li>/kind {bug, failing-test}</li>
|
||||
<li>/lgtm</li>
|
||||
<li>/approved</li>
|
||||
</ul>
|
||||
</td>
|
||||
<td>
|
||||
<!--Weeks 11+-->
|
||||
If you want your PR to get merged, it needs the following required labels and
|
||||
milestones, represented here by the Prow /commands it would take to add them:
|
||||
|
||||
### Normal Dev (Weeks 1-8)
|
||||
|
||||
- /sig {name}
|
||||
- /kind {type}
|
||||
- /lgtm
|
||||
- /approved
|
||||
|
||||
### Code Freeze (Weeks 9-11)
|
||||
|
||||
- /milestone {v1.y}
|
||||
- /sig {name}
|
||||
- /kind {bug, failing-test}
|
||||
- /lgtm
|
||||
- /approved
|
||||
|
||||
### Post-Release (Weeks 11+)
|
||||
|
||||
Return to 'Normal Dev' phase requirements:
|
||||
<ul>
|
||||
<li>/sig {name}</li>
|
||||
<li>/kind {type}</li>
|
||||
<li>/lgtm</li>
|
||||
<li>/approved</li>
|
||||
</ul>
|
||||
|
||||
Merges into the 1.y branch are now [via cherrypicks](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md), approved by release branch manager.
|
||||
</td>
|
||||
<td>
|
||||
<ul>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
- /sig {name}
|
||||
- /kind {type}
|
||||
- /lgtm
|
||||
- /approved
|
||||
|
||||
In the past there was a requirement for a milestone targeted pull
|
||||
request to have an associated GitHub issue opened, but this is no
|
||||
longer the case. Features are effectively GitHub issues or
|
||||
[KEPs](https://git.k8s.io/community/keps)
|
||||
which lead to subsequent PRs. The general labeling process should
|
||||
be consistent across artifact types.
|
||||
Merges into the 1.y branch are now [via cherrypicks](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md),
|
||||
approved by release branch manager.
|
||||
|
||||
In the past there was a requirement for a milestone targeted pull request to
|
||||
have an associated GitHub issue opened, but this is no longer the case.
|
||||
Features are effectively GitHub issues or [KEPs](https://git.k8s.io/community/keps)
|
||||
which lead to subsequent PRs. The general labeling process should be consistent
|
||||
across artifact types.
|
||||
|
||||
---
|
||||
|
||||
## Definitions
|
||||
|
||||
- *issue owners*: Creator, assignees, and user who moved the issue into a release milestone.
|
||||
- *issue owners*: Creator, assignees, and user who moved the issue into a
|
||||
release milestone
|
||||
- *release team*: Each Kubernetes release has a team doing project
|
||||
management tasks described
|
||||
[here](https://git.k8s.io/sig-release/release-team/README.md). The
|
||||
contact info for the team associated with any given release can be
|
||||
found [here](https://git.k8s.io/sig-release/releases/).
|
||||
- *Y days*: Refers to business days (using the location local to the release-manager M-F).
|
||||
management tasks described [here](https://git.k8s.io/sig-release/release-team/README.md).
|
||||
The contact info for the team associated with any given release can be found
|
||||
[here](https://git.k8s.io/sig-release/releases/).
|
||||
- *Y days*: Refers to business days (using the location local to the release
|
||||
manager M-F).
|
||||
- *enhancement*: see "[Is My Thing an Enhancement?](https://git.k8s.io/enhancements/README.md#is-my-thing-an-enhancement)
|
||||
- *[Enhancement Freeze](https://git.k8s.io/sig-release/releases/release_phases.md#enhancements-freeze)*: Usually during Week 4 of a release cycle: the deadline by which KEPs have to be completed in order for enhancements to be part of the current release
|
||||
- *[Exception Request](https://git.k8s.io/sig-release/releases/release_phases.md#exceptions)*: The process of requesting an extension on the deadline for a particular Enhancement
|
||||
- *[Code Freeze](https://git.k8s.io/sig-release/releases/release_phases.md#code-freeze)*: The period of ~4 weeks before the final release date, during which only critical bug fixes are merged into the release.
|
||||
- *[Pruning](https://git.k8s.io/sig-release/releases/release_phases.md#pruning)*: The process of removing an Enhancement from a release milestone if it is not fully implemented or is otherwise considered not stable.
|
||||
- *release milestone*: semantic version string or [GitHub milestone](https://help.github.com/articles/associating-milestones-with-issues-and-pull-requests/) referring to a release MAJOR.MINOR vX.Y version. See also [release versioning](http://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
|
||||
- *release branch*: Git branch "release-X.Y" created for the vX.Y milestone. Created at the time of the vX.Y-beta.0 release and maintained after the release for approximately 9 months with vX.Y.Z patch releases.
|
||||
- *[Enhancement Freeze](https://git.k8s.io/sig-release/releases/release_phases.md#enhancements-freeze)*:
|
||||
the deadline by which KEPs have to be completed in order for enhancements to
|
||||
be part of the current release
|
||||
- *[Exception Request](https://git.k8s.io/sig-release/releases/release_phases.md#exceptions)*:
|
||||
The process of requesting an extension on the deadline for a particular
|
||||
Enhancement
|
||||
- *[Code Freeze](https://git.k8s.io/sig-release/releases/release_phases.md#code-freeze)*:
|
||||
The period of ~4 weeks before the final release date, during which only
|
||||
critical bug fixes are merged into the release.
|
||||
- *[Pruning](https://git.k8s.io/sig-release/releases/release_phases.md#pruning)*:
|
||||
The process of removing an Enhancement from a release milestone if it is not
|
||||
fully implemented or is otherwise considered not stable.
|
||||
- *release milestone*: semantic version string or
|
||||
[GitHub milestone](https://help.github.com/articles/associating-milestones-with-issues-and-pull-requests/)
|
||||
referring to a release MAJOR.MINOR vX.Y version. See also
|
||||
[release versioning](http://git.k8s.io/community/contributors/design-proposals/release/versioning.md)
|
||||
- *release branch*: Git branch "release-X.Y" created for the vX.Y milestone.
|
||||
Created at the time of the vX.Y-beta.0 release and maintained after the
|
||||
release for approximately 9 months with vX.Y.Z patch releases.
|
||||
|
||||
## The Release Cycle
|
||||
|
||||
|
|
@ -121,138 +114,134 @@ be consistent across artifact types.
|
|||
|
||||
Kubernetes releases currently happen four times per year. The release
|
||||
process can be thought of as having three main phases:
|
||||
* Feature Definition
|
||||
* Implementation
|
||||
* Stabilization
|
||||
|
||||
But in reality this is an open source and agile project, with feature
|
||||
planning and implementation happening at all times. Given the
|
||||
project scale and globally distributed developer base, it is critical
|
||||
to project velocity to not rely on a trailing stabilization phase and
|
||||
rather have continuous integration testing which ensures the
|
||||
project is always stable so that individual commits can be
|
||||
- Feature Definition
|
||||
- Implementation
|
||||
- Stabilization
|
||||
|
||||
But in reality this is an open source and agile project, with feature planning
|
||||
and implementation happening at all times. Given the project scale and globally
|
||||
distributed developer base, it is critical to project velocity to not rely on a
|
||||
trailing stabilization phase and rather have continuous integration testing
|
||||
which ensures the project is always stable so that individual commits can be
|
||||
flagged as having broken something.
|
||||
|
||||
With ongoing feature definition through the year, some set of items
|
||||
will bubble up as targeting a given release. The **enhancement freeze**
|
||||
starts ~4 weeks into release cycle. By this point all intended
|
||||
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).
|
||||
With ongoing feature definition through the year, some set of items will bubble
|
||||
up as targeting a given release. The **enhancement freeze** starts ~4 weeks
|
||||
into release cycle. By this point all intended 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)
|
||||
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
|
||||
- kubernetes/enhancements
|
||||
- kubernetes/kubernetes
|
||||
- kubernetes/release
|
||||
- kubernetes/sig-release
|
||||
- kubernetes/test-infra
|
||||
|
||||
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 the master branch, milestones
|
||||
are auto-applied when the PR is created so no human management of the milestone
|
||||
is ever necessary.
|
||||
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 the
|
||||
master branch, milestones are auto-applied when the PR is created so no human
|
||||
management of the milestone is ever 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.
|
||||
|
||||
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.
|
||||
Implementation and bug fixing is ongoing across the cycle, but culminates in a
|
||||
code freeze period:
|
||||
|
||||
*"Milestone early and milestone often. Everyone will be happier."*
|
||||
|
||||
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.
|
||||
- The **code freeze*- starts in week ~10 and continues for ~2 weeks.
|
||||
Only critical bug fixes are accepted into the release codebase.
|
||||
|
||||
There are approximately two weeks following code freeze, and preceding
|
||||
release, during which all remaining critical issues must be resolved
|
||||
before release. This also gives time for documentation finalization.
|
||||
There are approximately two weeks following code freeze, and preceding release,
|
||||
during which all remaining critical issues must be resolved before release.
|
||||
This also gives time for documentation finalization.
|
||||
|
||||
When the code base is sufficiently stable, the master branch re-opens
|
||||
for general development and work begins there for the next release
|
||||
milestone. Any remaining modifications for the current release are cherry
|
||||
picked from master back to the release branch. The release is built from
|
||||
the release branch.
|
||||
When the code base is sufficiently stable, the master branch re-opens for
|
||||
general development and work begins there for the next release milestone. Any
|
||||
remaining modifications for the current release are cherry picked from master
|
||||
back to the release branch. The release is built from the release branch.
|
||||
|
||||
Following release, the [Release Branch
|
||||
Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager/README.md)
|
||||
cherry picks additional critical fixes from the master branch for
|
||||
a period of around 9 months, leaving an overlap of three release
|
||||
versions forward support. Thus, each release is part of a broader
|
||||
Kubernetes lifecycle:
|
||||
Following release, the [Release Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager/README.md)
|
||||
cherry picks additional critical fixes from the master branch for a period of
|
||||
around 9 months, leaving an overlap of three release versions forward support.
|
||||
Thus, each release is part of a broader Kubernetes lifecycle:
|
||||
|
||||
|
||||
|
||||
## Removal Of Items From The Milestone
|
||||
|
||||
Before getting too far into the process for adding an item to the
|
||||
milestone, please note:
|
||||
Before getting too far into the process for adding an item to the milestone,
|
||||
please note:
|
||||
|
||||
Members of the Release Team may remove Issues from the milestone
|
||||
if they or the responsible SIG determine that the issue is not
|
||||
actually blocking the release and is unlikely to be resolved in a
|
||||
timely fashion.
|
||||
Members of the Release Team may remove Issues from the milestone if they or the
|
||||
responsible SIG determine that the issue is not actually blocking the release
|
||||
and is unlikely to be resolved in a timely fashion.
|
||||
|
||||
Members of the Release Team may remove PRs from the milestone for
|
||||
any of the following, or similar, reasons:
|
||||
Members of the Release Team may remove PRs from the milestone for any of the
|
||||
following, or similar, reasons:
|
||||
|
||||
* PR is potentially de-stabilizing and is not needed to resolve a blocking issue;
|
||||
* PR is a new, late feature PR and has not gone through the features process or the exception process;
|
||||
* There is no responsible SIG willing to take ownership of the PR and resolve any follow-up issues with it;
|
||||
* PR is not correctly labelled;
|
||||
* Work has visibly halted on the PR and delivery dates are uncertain or late.
|
||||
- PR is potentially de-stabilizing and is not needed to resolve a blocking
|
||||
issue
|
||||
- PR is a new, late feature PR and has not gone through the features process or
|
||||
the exception process
|
||||
- There is no responsible SIG willing to take ownership of the PR and resolve
|
||||
any follow-up issues with it
|
||||
- PR is not correctly labelled
|
||||
- Work has visibly halted on the PR and delivery dates are uncertain or late
|
||||
|
||||
While members of the Release Team will help with labelling and
|
||||
contacting SIG(s), it is the responsibility of the submitter to
|
||||
categorize PRs, and to secure support from the relevant SIG to
|
||||
guarantee that any breakage caused by the PR will be rapidly resolved.
|
||||
While members of the Release Team will help with labelling and contacting
|
||||
SIG(s), it is the responsibility of the submitter to categorize PRs, and to
|
||||
secure support from the relevant SIG to guarantee that any breakage caused by
|
||||
the PR will be rapidly resolved.
|
||||
|
||||
Where additional action is required, an attempt at human to human
|
||||
escalation will be made by the release team through the following
|
||||
channels:
|
||||
Where additional action is required, an attempt at human to human escalation
|
||||
will be made by the release team through the following channels:
|
||||
|
||||
- Comment in GitHub mentioning the SIG team and SIG members as appropriate for the issue type
|
||||
- Comment in GitHub mentioning the SIG team and SIG members as appropriate for
|
||||
the issue type
|
||||
- Emailing the SIG mailing list
|
||||
- bootstrapped with group email addresses from the [community sig list](/sig-list.md)
|
||||
- bootstrapped with group email addresses from the
|
||||
[community sig list](/sig-list.md)
|
||||
- optionally also directly addressing SIG leadership or other SIG members
|
||||
- Messaging the SIG's Slack channel
|
||||
- bootstrapped with the slackchannel and SIG leadership from the [community sig list](/sig-list.md)
|
||||
- bootstrapped with the slackchannel and SIG leadership from the
|
||||
[community sig list](/sig-list.md)
|
||||
- optionally directly "@" mentioning SIG leadership or others by handle
|
||||
|
||||
## Adding An Item To The Milestone
|
||||
|
||||
### Milestone Maintainers
|
||||
|
||||
The members of the GitHub [“kubernetes-milestone-maintainers”
|
||||
team](https://github.com/orgs/kubernetes/teams/kubernetes-milestone-maintainers/members)
|
||||
The members of the GitHub
|
||||
[“kubernetes-milestone-maintainers” team](https://github.com/orgs/kubernetes/teams/kubernetes-milestone-maintainers/members)
|
||||
are entrusted with the responsibility of specifying the release milestone on
|
||||
GitHub artifacts. This group is [maintained by
|
||||
SIG-Release](https://git.k8s.io/sig-release/release-team/README.md#milestone-maintainers)
|
||||
GitHub artifacts. This group is [maintained by
|
||||
SIG Release](https://git.k8s.io/sig-release/release-team/README.md#milestone-maintainers)
|
||||
and has representation from the various SIGs' leadership.
|
||||
|
||||
### Feature additions
|
||||
|
||||
Feature planning and definition takes many forms today, but a typical
|
||||
example might be a large piece of work described in a
|
||||
[KEP](https://git.k8s.io/community/keps), with associated
|
||||
task issues in GitHub. When the plan has reached an implementable state and
|
||||
work is underway, the feature or parts thereof are targeted for an upcoming
|
||||
milestone by creating GitHub issues and marking them with the Prow "/milestone"
|
||||
command.
|
||||
Feature planning and definition takes many forms today, but a typical example
|
||||
might be a large piece of work described in a
|
||||
[KEP](https://git.k8s.io/community/keps), with associated task issues in
|
||||
GitHub. When the plan has reached an implementable state and work is underway,
|
||||
the feature or parts thereof are targeted for an upcoming milestone by creating
|
||||
GitHub issues and marking them with the Prow "/milestone" command.
|
||||
|
||||
For the first ~4 weeks into the release cycle, the release team's
|
||||
Enhancements Lead will interact with SIGs and feature owners via GitHub,
|
||||
Slack, and SIG meetings to capture all required planning artifacts.
|
||||
For the first ~4 weeks into the release cycle, the release team's Enhancements
|
||||
Lead will interact with SIGs and feature owners via GitHub, Slack, and SIG
|
||||
meetings to capture all required planning artifacts.
|
||||
|
||||
If you have a feature to target for an upcoming release milestone, begin a
|
||||
conversation with your SIG leadership and with that release's Enhancements
|
||||
|
|
@ -260,73 +249,74 @@ Lead.
|
|||
|
||||
### Issue additions
|
||||
|
||||
Issues are marked as targeting a milestone via the Prow
|
||||
"/milestone" command.
|
||||
Issues are marked as targeting a milestone via the Prow "/milestone" command.
|
||||
|
||||
The release team's [Bug Triage
|
||||
Lead](https://git.k8s.io/sig-release/release-team/role-handbooks/bug-triage/README.md) and overall community watch
|
||||
incoming issues and triage them, as described in the contributor
|
||||
guide section on [issue triage](/contributors/guide/issue-triage.md).
|
||||
The release team's [Bug Triage Lead](https://git.k8s.io/sig-release/release-team/role-handbooks/bug-triage/README.md)
|
||||
and overall community watch incoming issues and triage them, as described in
|
||||
the contributor guide section on
|
||||
[issue triage](/contributors/guide/issue-triage.md).
|
||||
|
||||
Marking issues with the milestone provides the community better
|
||||
visibility regarding when an issue was observed and by when the community
|
||||
feels it must be resolved. During code freeze, to merge a PR it is required
|
||||
that a release milestone is set.
|
||||
Marking issues with the milestone provides the community better visibility
|
||||
regarding when an issue was observed and by when the community feels it must be
|
||||
resolved. During code freeze, to merge a PR it is required that a release
|
||||
milestone is set.
|
||||
|
||||
An open issue is no longer required for a PR, but open issues and
|
||||
associated PRs should have synchronized labels. For example a high
|
||||
priority bug issue might not have its associated PR merged if the PR is
|
||||
only marked as lower priority.
|
||||
An open issue is no longer required for a PR, but open issues and associated
|
||||
PRs should have synchronized labels. For example a high priority bug issue
|
||||
might not have its associated PR merged if the PR is only marked as lower
|
||||
priority.
|
||||
|
||||
### PR Additions
|
||||
|
||||
PRs are marked as targeting a milestone via the Prow
|
||||
"/milestone" command.
|
||||
PRs are marked as targeting a milestone via the Prow "/milestone" command.
|
||||
|
||||
This is a blocking requirement during code freeze as described above.
|
||||
|
||||
## Other Required Labels
|
||||
|
||||
*Note* [Here is the list of labels and their use and purpose.](https://git.k8s.io/test-infra/label_sync/labels.md#labels-that-apply-to-all-repos-for-both-issues-and-prs)
|
||||
[Here is the list of labels and their use and purpose.](https://git.k8s.io/test-infra/label_sync/labels.md#labels-that-apply-to-all-repos-for-both-issues-and-prs)
|
||||
|
||||
### SIG Owner Label
|
||||
|
||||
The SIG owner label defines the SIG to which we escalate if a
|
||||
milestone issue is languishing or needs additional attention. If
|
||||
there are no updates after escalation, the issue may be automatically
|
||||
removed from the milestone.
|
||||
The SIG owner label defines the SIG to which we escalate if a milestone issue
|
||||
is languishing or needs additional attention. If there are no updates after
|
||||
escalation, the issue may be automatically removed from the milestone.
|
||||
|
||||
These are added with the Prow "/sig" command. For example to add
|
||||
the label indicating SIG Storage is responsible, comment with `/sig
|
||||
storage`.
|
||||
These are added with the Prow "/sig" command. For example to add the label
|
||||
indicating SIG Storage is responsible, comment with `/sig storage`.
|
||||
|
||||
### Priority Label
|
||||
|
||||
Priority labels are used to determine an escalation path before
|
||||
moving issues out of the release milestone. They are also used to
|
||||
determine whether or not a release should be blocked on the resolution
|
||||
of the issue.
|
||||
Priority labels are used to determine an escalation path before moving issues
|
||||
out of the release milestone. They are also used to determine whether or not a
|
||||
release should be blocked on the resolution of the issue.
|
||||
|
||||
- `priority/critical-urgent`: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels.
|
||||
- `priority/critical-urgent`: Never automatically move out of a release
|
||||
milestone; continually escalate to contributor and SIG through all available
|
||||
channels.
|
||||
- considered a release blocking issue
|
||||
- code freeze: issue owner update frequency: daily
|
||||
- would require a patch release if left undiscovered until after the minor release.
|
||||
- `priority/important-soon`: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts.
|
||||
- would require a patch release if left undiscovered until after the minor
|
||||
release
|
||||
- `priority/important-soon`: Escalate to the issue owners and SIG owner; move
|
||||
out of milestone after several unsuccessful escalation attempts.
|
||||
- not considered a release blocking issue
|
||||
- would not require a patch release
|
||||
- will automatically be moved out of the release milestone at code freeze after a 4 day grace period
|
||||
- `priority/important-longterm`: Escalate to the issue owners; move out of the milestone after 1 attempt.
|
||||
- will automatically be moved out of the release milestone at code freeze
|
||||
after a 4 day grace period
|
||||
- `priority/important-longterm`: Escalate to the issue owners; move out of the
|
||||
milestone after 1 attempt.
|
||||
- even less urgent / critical than `priority/important-soon`
|
||||
- moved out of milestone more aggressively than `priority/important-soon`
|
||||
|
||||
### Issue/PR Kind Label
|
||||
|
||||
The issue kind is used to help identify the types of changes going
|
||||
into the release over time. This may allow the release team to
|
||||
develop a better understanding of what sorts of issues we would
|
||||
miss with a faster release cadence.
|
||||
The issue kind is used to help identify the types of changes going into the
|
||||
release over time. This may allow the release team to develop a better
|
||||
understanding of what sorts of issues we would miss with a faster release
|
||||
cadence.
|
||||
|
||||
For release targeted issues, including pull requests, one of the following
|
||||
For release targeted issues, including pull requests, one of the following
|
||||
issue kind labels must be set:
|
||||
|
||||
- `kind/api-change`: Adds, removes, or changes an API
|
||||
|
|
|
|||
Loading…
Reference in New Issue