You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Be aware the cherry-pick script assumes you have a git remote called
79
+
`upstream` that points at the Kubernetes github org.
80
+
81
+
Please see our [recommended Git workflow](https://git.k8s.io/community/contributors/guide/github-workflow.md#workflow).
82
+
83
+
- You will need to run the cherry-pick script separately for each patch
84
+
release you want to cherry-pick to.
85
+
86
+
- Your cherry-pick PR will immediately get the
87
+
`do-not-merge/cherry-pick-not-approved` label.
88
+
89
+
[Normal rules apply for code merge](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/release.md#tldr),
90
+
with some additional caveats outlined in the next section of this document.
87
91
88
92
## Cherry-pick Review
89
93
@@ -101,81 +105,91 @@ or include in a comment the `/release-note-none` command.
101
105
Cherry-pick pull requests are reviewed slightly differently than normal
102
106
pull requests on the master branch in that they:
103
107
104
-
* Are by default expected to be `kind/bug` and `priority/critical-urgent`.
105
-
106
-
* Milestones must be set on the PR reflecting the milestone for the target
107
-
release branch (for example, milestone v1.11 for a cherry-pick onto branch
108
-
release-1.11). This is normally done for you by automation.
109
-
110
-
* Have one additional level of review in that they must be approved specifically
111
-
for cherry-pick by branch approvers.
112
-
113
-
The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager)
114
-
will triage PRs targeted to the next .0 minor release branch up until the
115
-
release, while the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager)
116
-
will handle all cherry-picks to patch releases.
117
-
118
-
The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager)
119
-
or the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager)
120
-
are the final authority on branch approval by removing the `do-not-merge/cherry-pick-not-approved`
121
-
label and triggering a merge into the target branch.
122
-
123
-
The team scrubs through incoming cherry-picks on at least a weekly basis, daily during
124
-
burndown ahead of a .0 release. Ahead of point releases, reminders of the
125
-
cherry-pick deadline will be sent out to the community. Cherry-pick PRs are
126
-
often metered into the release branches to give more deliberate CI signal across
127
-
changes. For this reason your cherry-pick must be ready to merge ahead of
128
-
the cherry-pick deadline, but those candidates may be merged during the days
129
-
between the deadline and release.
130
-
131
-
Open cherry-pick PRs which do not land in the current release will
132
-
continue to be tracked by the team for consideration for inclusion in a next
133
-
patch release.
134
-
135
-
If you are concerned about the status of your cherry-pick, err on the
136
-
side of overcommunicating and reach out to the branch reviewer(s):
137
-
138
-
* During code freeze or after code thaw and ahead of a .0 release, to get attention on a cherry-pick by the current
139
-
release team members see the [appropriate release folder](https://git.k8s.io/sig-release/releases)
140
-
for the target release's team contact information. You may cc them with
141
-
`@<githubusername>` on your cherry-pick PR.
142
-
143
-
* 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.
108
+
- Are by default expected to be `kind/bug` and `priority/critical-urgent`.
109
+
110
+
- Milestones must be set on the PR reflecting the milestone for the target
111
+
release branch (for example, milestone v1.11 for a cherry-pick onto branch
112
+
release-1.11). This is normally done for you by automation.
113
+
114
+
- Have one additional level of review in that they must be approved
115
+
specifically for cherry-pick by branch approvers.
116
+
117
+
The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager)
118
+
will triage PRs targeted to the next .0 minor release branch up until the
119
+
release, while the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager)
120
+
will handle all cherry-picks to patch releases.
121
+
122
+
The [Branch Manager](https://git.k8s.io/sig-release/release-team/role-handbooks/branch-manager)
123
+
or the [Patch Release Team](https://git.k8s.io/sig-release/release-team/role-handbooks/patch-release-manager)
124
+
are the final authority on branch approval by removing the
125
+
`do-not-merge/cherry-pick-not-approved` label and triggering a merge into the
126
+
target branch.
127
+
128
+
The team scrubs through incoming cherry-picks on at least a weekly basis,
129
+
daily during burndown ahead of a .0 release. Ahead of point releases,
130
+
reminders of the cherry-pick deadline will be sent out to the community.
131
+
Cherry-pick PRs are often metered into the release branches to give more
132
+
deliberate CI signal across changes. For this reason your cherry-pick must be
133
+
ready to merge ahead of the cherry-pick deadline, but those candidates may be
134
+
merged during the days between the deadline and release.
135
+
136
+
Open cherry-pick PRs which do not land in the current release will
137
+
continue to be tracked by the team for consideration for inclusion in a next
138
+
patch release.
139
+
140
+
If you are concerned about the status of your cherry-pick, err on the
141
+
side of overcommunicating and reach out to the branch reviewer(s):
142
+
143
+
- During code freeze or after code thaw and ahead of a .0 release, to get
144
+
attention on a cherry-pick by the current release team members see the
145
+
[appropriate release folder](https://git.k8s.io/sig-release/releases) for
146
+
the target release's team contact information. You may cc them with
147
+
`@<githubusername>` on your cherry-pick PR.
148
+
- For prior branches, check the [patch release schedule](https://git.k8s.io/sig-release/releases/patch-releases.md),
149
+
which includes contact information for the patch release team.
144
150
145
151
## Searching for Cherry-picks
146
152
147
153
-[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)
148
154
149
155
-[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)
150
156
151
-
152
157
## Troubleshooting Cherry-picks
153
158
154
-
Contributors may encounter some of the following difficulties when initiating a cherry-pick.
159
+
Contributors may encounter some of the following difficulties when initiating a
160
+
cherry-pick.
155
161
156
-
- A cherry-pick PR does not apply cleanly against an old release branch.
157
-
In that case, you will need to manually fix conflicts.
162
+
- A cherry-pick PR does not apply cleanly against an old release branch. In
163
+
that case, you will need to manually fix conflicts.
158
164
159
-
- The cherry-pick PR includes code that does not pass CI tests.
160
-
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.
161
-
Alternatively, you can create a new PR, which is noisier.
165
+
- The cherry-pick PR includes code that does not pass CI tests. In such a case
166
+
you will have to fetch the auto-generated branch from your fork, amend the
167
+
problematic commit and force push to the auto-generated branch.
168
+
Alternatively, you can create a new PR, which is noisier.
162
169
163
170
## Cherry-picks for unsupported releases
164
171
165
-
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.
172
+
The release team only supports & patches `n-3` releases (`n` being the latest
173
+
release of Kubernetes). In January of 2019 the community discovered a
174
+
regression, that was introduced in a post-release patch, but was currently no
175
+
longer supported.
166
176
167
-
As discussed in a sig-release meeting on 2019-01-15, a fix was backported to the non supported version.
177
+
As discussed in a sig-release meeting on 2019-01-15, a fix was backported to
0 commit comments