1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
|
# SIG Node Cherry-Pick Management Process
Kubernetes supports [multiple release versions] simultaneously. How do new
fixes make it into earlier versions, when we only develop against one version
at a time?
We [cherry-pick] them!
To assist the Release Team, a member of SIG Node can volunteer to oversee
Node's cherry-picks. This guide is intended to document that person's
responsibilities.
[multiple release versions]: https://kubernetes.io/docs/setup/release/version-skew-policy/
[cherry-pick]: /contributors/devel/sig-release/cherry-picks.md
## Release timeline
SIG Release regularly (on a ~monthly cadence) ships [patch releases]. Every
release, the Release Team publishes a list of [target dates] with **cherry-pick
deadlines**.
SIG Node's responsibility is to ensure that all patches that we want
cherry-picked to previous releases must be [triaged], prioritized, LGTM'd, and
approved by the deadline.
[patch releases]: https://github.com/kubernetes/sig-release/blob/master/release-engineering/versioning.md#patch-releases
[target dates]: https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md#upcoming-monthly-releases
[triaged]: triage.md
## Monthly cherry-pick process
Throughout the release cycle, merged bugfixes should be evaluated for inclusion
as cherry-picks. Any bugs marked **critical-urgent** should be considered. Some
**important-soon** bugs may also be considered if they are sufficiently
contained and meet the criteria above.
**Only** bug fixes should be considered for backports. Patches should be merged
and soaked in CI for at least a week.
To create a cherry-pick PR, you can use the `./hack/cherry_pick_pull.sh`
script. Read through the [cherry pick documentation][cherry-pick] for details
on that process.
## Preparing the SIG's patches
The week of the cherry-pick deadline, create a Slack thread ([example
thread]) in the [#sig-node] channel to track the cherry-picks.
To determine what fixes need to be cherry-picked, you can use the [SIG Node PR
Board with the cherry-pick filter view]. Track each change considered for
inclusion individually.
Release branches are typically kept in sync. This means that bugfixes should be
backported to all applicable supported branches. The [cherry pick
schedule][target dates] will include a list of all supported releases and their
end-of-life (EOL) dates.
In the first comment in the Slack thread, track each patch and the status of
backports to each branch. Some examples of what you might write are available
below for reference. You can use the rest of the Slack thread for discussion.
Typically, we will backport 2-3 patches per monthly cycle.
[example thread]: https://kubernetes.slack.com/archives/C0BP8PW9G/p1617919799137500
[#sig-node]: https://kubernetes.slack.com/messages/sig-node
[SIG Node PR Board with the cherry-pick filter view]: https://github.com/orgs/kubernetes/projects/49?card_filter_query=label%3Ado-not-merge%2Fcherry-pick-not-approved
### Example cherry-pick: all supported branches
Consider the following PR to backport:
https://github.com/kubernetes/kubernetes/pull/99600
This fixes broken accounting in a beta feature that has been beta for the past
three releases.
Since it is a **critical-urgent** fix, it is eligible to be backported to all
affected releases. During the 1.21 cycle, that means 1.18 through 1.20.
Thus, our Slack update should look like the following:
> Count pod overhead as an entity's resource usage https://github.com/kubernetes/kubernetes/pull/99600
> - 1.18 https://github.com/kubernetes/kubernetes/pull/100039
> - 1.19 https://github.com/kubernetes/kubernetes/pull/100038
> - 1.20 https://github.com/kubernetes/kubernetes/pull/100037
You can use this list and the Node Triage board to ensure all PRs have LGTMs
and approvals, so they are ready for the Release Team by the cherry-pick
deadline.
### Example cherry-pick: limited release support
Consider the following PR to backport:
https://github.com/kubernetes/kubernetes/pull/98088
This fixes an issue with an alpha feature introduced in 1.20, so it is only
eligible to backport to 1.20 during the 1.21 cycle.
In this case,
- the fix only affects feature-gated code
- the fix addresses a serious bug (repeatedly acquiring a lock unnecessarily)
- the fix is small
Hence, we included it in our backport.
Thus, our Slack update should look like the following:
> Fix repeatedly acquire the inhibit lock https://github.com/kubernetes/kubernetes/pull/98088
> - 1.18 N/A, only affects 1.20+
> - 1.19 N/A, only affects 1.20+
> - 1.20 https://github.com/kubernetes/kubernetes/pull/99255
### Example cherry-pick: rejected
Consider the following PR to backport:
https://github.com/kubernetes/kubernetes/pull/98376
In this case,
- the fix is a relatively involved refactor
- the fix caused a known test regression
- the regression fix is not being backported
- the priority of the fix was **important-longterm**
Hence, this would **not** be an appropriate patch to cherry-pick. SIG Node
chose to close its cherry-pick PRs.
|
