devel/sig-release: Initial link cleanup
Signed-off-by: Stephen Augustus <saugustus@vmware.com>
This commit is contained in:
Stephen Augustus
parent
4964c404eb
commit
dbe8c6a95a
|
|
@ -19,7 +19,7 @@ branches.
|
|||
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 release branch exists (example: [`release-1.18`](https://github.com/kubernetes/kubernetes/tree/release-1.18))
|
||||
- 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
|
||||
|
|
@ -71,14 +71,18 @@ continue, bolster your case by supplementing your PR with e.g.,
|
|||
## 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`
|
||||
`upstream/release-3.14`:
|
||||
|
||||
```shell
|
||||
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).
|
||||
Please see our [recommended Git workflow](/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.
|
||||
|
|
@ -86,7 +90,7 @@ continue, bolster your case by supplementing your PR with e.g.,
|
|||
- 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),
|
||||
[Normal rules apply for code merge](/contributors/devel/sig-release/release.md#tldr),
|
||||
with some additional caveats outlined in the next section of this document.
|
||||
|
||||
## Cherry-pick Review
|
||||
|
|
@ -99,7 +103,7 @@ except the release note stanza will auto-populate from the master
|
|||
branch pull request from which the cherry-pick originated. If this
|
||||
is unsuccessful the `do-not-merge/release-note-label-needed` label
|
||||
will be applied and the cherry-pick author must edit the pull request
|
||||
description to [add a release note](https://git.k8s.io/community/contributors/guide/release-notes.md)
|
||||
description to [add a release note](/contributors/guide/release-notes.md)
|
||||
or include in a comment the `/release-note-none` command.
|
||||
|
||||
Cherry-pick pull requests are reviewed slightly differently than normal
|
||||
|
|
@ -114,15 +118,12 @@ pull requests on the master branch in that they:
|
|||
- 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 [Release Managers][release-managers] are the final approvers on release
|
||||
branches.
|
||||
|
||||
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
|
||||
Approval is signified by a Release Manager manually applying the
|
||||
`cherry-pick-approved` label. This action removes the
|
||||
`do-not-merge/cherry-pick-not-approved` label and triggers a merge into the
|
||||
target branch.
|
||||
|
||||
The team scrubs through incoming cherry-picks on at least a weekly basis,
|
||||
|
|
@ -150,9 +151,10 @@ pull requests on the master branch in that they:
|
|||
|
||||
## Searching for Cherry-picks
|
||||
|
||||
- [A sample search on kubernetes/kubernetes pull requests that are labeled as `cherry-pick-approved`](https://github.com/kubernetes/kubernetes/pulls?q=is%3Aopen+is%3Apr+label%3Acherry-pick-approved)
|
||||
Examples (based on cherry picks targeting the `release-1.18` branch):
|
||||
|
||||
- [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)
|
||||
- [`cherry-pick-approved`](https://github.com/kubernetes/kubernetes/pulls?q=is%3Aopen+is%3Apr+label%3Acherry-pick-approved+base%3Arelease-1.18)
|
||||
- [`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+base%3Arelease-1.18)
|
||||
|
||||
## Troubleshooting Cherry-picks
|
||||
|
||||
|
|
@ -177,7 +179,7 @@ longer supported.
|
|||
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)
|
||||
Reference PR: [#72860](https://github.com/kubernetes/kubernetes/pull/72860)
|
||||
|
||||
The specific criteria driving the decision was:
|
||||
|
||||
|
|
@ -193,3 +195,5 @@ A note about the specific case in [#72860](https://github.com/kubernetes/kuberne
|
|||
- 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
|
||||
|
||||
[release-managers]: https://git.k8s.io/sig-release/release-managers.md
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Getting Kubernetes Builds
|
||||
|
||||
You can use [hack/get-build.sh](http://releases.k8s.io/HEAD/hack/get-build.sh)
|
||||
You can use [hack/get-build.sh](https://git.k8s.io/kubernetes/hack/get-build.sh)
|
||||
to get a build or to use as a reference on how to get the most recent builds
|
||||
with curl. With `get-build.sh` you can grab the most recent stable build, the
|
||||
most recent release candidate, or the most recent build to pass our ci and gce
|
||||
|
|
|
|||
|
|
@ -66,14 +66,13 @@ Return to 'Normal Dev' phase requirements:
|
|||
- /lgtm
|
||||
- /approved
|
||||
|
||||
Merges into the 1.y branch are now [via cherrypicks](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md),
|
||||
Merges into the 1.y branch are now [via cherry picks](/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.
|
||||
Features are effectively GitHub issues or [KEPs][keps] which lead to subsequent
|
||||
PRs. The general labeling process should be consistent across artifact types.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -101,9 +100,9 @@ across artifact types.
|
|||
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/)
|
||||
[GitHub milestone](https://help.github.com/en/github/managing-your-work-on-github/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 versioning](/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.
|
||||
|
|
@ -172,10 +171,7 @@ 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:
|
||||
Each release is part of a broader Kubernetes lifecycle:
|
||||
|
||||
|
||||
|
||||
|
|
@ -212,32 +208,31 @@ will be made by the release team through the following channels:
|
|||
the issue type
|
||||
- Emailing the SIG mailing list
|
||||
- bootstrapped with group email addresses from the
|
||||
[community sig list](/sig-list.md)
|
||||
[community sig list][sig-list]
|
||||
- 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)
|
||||
[community sig list][sig-list]
|
||||
- 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)
|
||||
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)
|
||||
and has representation from the various SIGs' leadership.
|
||||
The members of the [`milestone-maintainers`](https://github.com/orgs/kubernetes/teams/milestone-maintainers/members)
|
||||
GitHub team are entrusted with the responsibility of specifying the release
|
||||
milestone on GitHub artifacts.
|
||||
|
||||
This group is [maintained](https://git.k8s.io/sig-release/release-team/README.md#milestone-maintainers)
|
||||
by SIG Release 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.
|
||||
might be a large piece of work described in a [KEP][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
|
||||
|
|
@ -327,3 +322,6 @@ issue kind labels must be set:
|
|||
- `kind/failing-test`: CI test case is failing consistently.
|
||||
- `kind/feature`: New functionality.
|
||||
- `kind/flake`: CI test case is showing intermittent failures.
|
||||
|
||||
[keps]: https://git.k8s.io/enhancements/keps
|
||||
[sig-list]: /sig-list.md
|
||||
|
|
|
|||
Loading…
Reference in New Issue