Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
docs: stable-kernel-rules: remove code-labels tags and a indention level
Remove the 'code-block:: none' labels and switch to the shorter '::' to
reduce noise.
Remove a unneeded level of indentation, as that reduces the chance that
readers have to scroll sideways in some of the code blocks.
No text changes. Rendered html output looks like before, except for the
different level of indentation.
CC: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/755afbeafc8e1457154cb4b30ff4397f34326679.1714367921.git.linux@leemhuis.info
authored by
Thorsten Leemhuis
and committed by
Jonathan Corbet
5db34f5b
2263c40e
+101
-122
+101
-122
Documentation/process/stable-kernel-rules.rst
+101
-122
Documentation/process/stable-kernel-rules.rst
···
6
6
Rules on what kind of patches are accepted, and which ones are not, into the
7
7
"-stable" tree:
8
8
9
-
- It or an equivalent fix must already exist in Linux mainline (upstream).
10
-
- It must be obviously correct and tested.
11
-
- It cannot be bigger than 100 lines, with context.
12
-
- It must follow the
13
-
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
14
-
rules.
15
-
- It must either fix a real bug that bothers people or just add a device ID.
16
-
To elaborate on the former:
9
+
- It or an equivalent fix must already exist in Linux mainline (upstream).
10
+
- It must be obviously correct and tested.
11
+
- It cannot be bigger than 100 lines, with context.
12
+
- It must follow the
13
+
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
14
+
rules.
15
+
- It must either fix a real bug that bothers people or just add a device ID.
16
+
To elaborate on the former:
17
17
18
-
- It fixes a problem like an oops, a hang, data corruption, a real security
19
-
issue, a hardware quirk, a build error (but not for things marked
20
-
CONFIG_BROKEN), or some "oh, that's not good" issue.
21
-
- Serious issues as reported by a user of a distribution kernel may also
22
-
be considered if they fix a notable performance or interactivity issue.
23
-
As these fixes are not as obvious and have a higher risk of a subtle
24
-
regression they should only be submitted by a distribution kernel
25
-
maintainer and include an addendum linking to a bugzilla entry if it
26
-
exists and additional information on the user-visible impact.
27
-
- No "This could be a problem..." type of things like a "theoretical race
28
-
condition", unless an explanation of how the bug can be exploited is also
29
-
provided.
30
-
- No "trivial" fixes without benefit for users (spelling changes, whitespace
31
-
cleanups, etc).
18
+
- It fixes a problem like an oops, a hang, data corruption, a real security
19
+
issue, a hardware quirk, a build error (but not for things marked
20
+
CONFIG_BROKEN), or some "oh, that's not good" issue.
21
+
- Serious issues as reported by a user of a distribution kernel may also
22
+
be considered if they fix a notable performance or interactivity issue.
23
+
As these fixes are not as obvious and have a higher risk of a subtle
24
+
regression they should only be submitted by a distribution kernel
25
+
maintainer and include an addendum linking to a bugzilla entry if it
26
+
exists and additional information on the user-visible impact.
27
+
- No "This could be a problem..." type of things like a "theoretical race
28
+
condition", unless an explanation of how the bug can be exploited is also
29
+
provided.
30
+
- No "trivial" fixes without benefit for users (spelling changes, whitespace
31
+
cleanups, etc).
32
32
33
33
34
34
Procedure for submitting patches to the -stable tree
···
42
42
43
43
There are three options to submit a change to -stable trees:
44
44
45
-
1. Add a 'stable tag' to the description of a patch you then submit for
46
-
mainline inclusion.
47
-
2. Ask the stable team to pick up a patch already mainlined.
48
-
3. Submit a patch to the stable team that is equivalent to a change already
49
-
mainlined.
45
+
1. Add a 'stable tag' to the description of a patch you then submit for
46
+
mainline inclusion.
47
+
2. Ask the stable team to pick up a patch already mainlined.
48
+
3. Submit a patch to the stable team that is equivalent to a change already
49
+
mainlined.
50
50
51
51
The sections below describe each of the options in more detail.
52
52
···
68
68
********
69
69
70
70
To have a patch you submit for mainline inclusion later automatically picked up
71
-
for stable trees, add the tag
71
+
for stable trees, add this tag in the sign-off area::
72
72
73
-
.. code-block:: none
73
+
Cc: stable@vger.kernel.org
74
74
75
-
Cc: stable@vger.kernel.org
76
-
77
-
in the sign-off area. Once the patch is mainlined it will be applied to the
78
-
stable tree without anything else needing to be done by the author or
79
-
subsystem maintainer.
75
+
Once the patch is mainlined it will be applied to the stable tree without
76
+
anything else needing to be done by the author or subsystem maintainer.
80
77
81
78
To sent additional instructions to the stable team, use a shell-style inline
82
79
comment to pass arbitrary or predefined notes:
83
80
84
-
* Specify any additional patch prerequisites for cherry picking:
81
+
* Specify any additional patch prerequisites for cherry picking::
85
82
86
-
.. code-block:: none
83
+
Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
84
+
Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
85
+
Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
86
+
Cc: <stable@vger.kernel.org> # 3.3.x
87
+
Signed-off-by: Ingo Molnar <mingo@elte.hu>
87
88
88
-
Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
89
-
Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
90
-
Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
91
-
Cc: <stable@vger.kernel.org> # 3.3.x
92
-
Signed-off-by: Ingo Molnar <mingo@elte.hu>
89
+
The tag sequence has the meaning of::
93
90
94
-
The tag sequence has the meaning of:
91
+
git cherry-pick a1f84a3
92
+
git cherry-pick 1b9508f
93
+
git cherry-pick fd21073
94
+
git cherry-pick <this commit>
95
95
96
-
.. code-block:: none
96
+
Note that for a patch series, you do not have to list as prerequisites the
97
+
patches present in the series itself. For example, if you have the following
98
+
patch series::
97
99
98
-
git cherry-pick a1f84a3
99
-
git cherry-pick 1b9508f
100
-
git cherry-pick fd21073
101
-
git cherry-pick <this commit>
100
+
patch1
101
+
patch2
102
102
103
-
Note that for a patch series, you do not have to list as prerequisites the
104
-
patches present in the series itself. For example, if you have the following
105
-
patch series:
103
+
where patch2 depends on patch1, you do not have to list patch1 as
104
+
prerequisite of patch2 if you have already marked patch1 for stable
105
+
inclusion.
106
106
107
-
.. code-block:: none
107
+
* Point out kernel version prerequisites::
108
108
109
-
patch1
110
-
patch2
109
+
Cc: <stable@vger.kernel.org> # 3.3.x
111
110
112
-
where patch2 depends on patch1, you do not have to list patch1 as
113
-
prerequisite of patch2 if you have already marked patch1 for stable
114
-
inclusion.
111
+
The tag has the meaning of::
115
112
116
-
* Point out kernel version prerequisites:
113
+
git cherry-pick <this commit>
117
114
118
-
.. code-block:: none
115
+
For each "-stable" tree starting with the specified version.
119
116
120
-
Cc: <stable@vger.kernel.org> # 3.3.x
117
+
Note, such tagging is unnecessary if the stable team can derive the
118
+
appropriate versions from Fixes: tags.
121
119
122
-
The tag has the meaning of:
120
+
* Delay pick up of patches::
123
121
124
-
.. code-block:: none
122
+
Cc: <stable@vger.kernel.org> # after -rc3
125
123
126
-
git cherry-pick <this commit>
124
+
* Point out known problems::
127
125
128
-
For each "-stable" tree starting with the specified version.
129
-
130
-
Note, such tagging is unnecessary if the stable team can derive the
131
-
appropriate versions from Fixes: tags.
132
-
133
-
* Delay pick up of patches:
134
-
135
-
.. code-block:: none
136
-
137
-
Cc: <stable@vger.kernel.org> # after -rc3
138
-
139
-
* Point out known problems:
140
-
141
-
.. code-block:: none
142
-
143
-
Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
126
+
Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
144
127
145
128
.. _option_2:
146
129
···
143
160
Send the patch, after verifying that it follows the above rules, to
144
161
stable@vger.kernel.org and mention the kernel versions you wish it to be applied
145
162
to. When doing so, you must note the upstream commit ID in the changelog of your
146
-
submission with a separate line above the commit text, like this:
163
+
submission with a separate line above the commit text, like this::
147
164
148
-
.. code-block:: none
165
+
commit <sha1> upstream.
149
166
150
-
commit <sha1> upstream.
167
+
Or alternatively::
151
168
152
-
or alternatively:
153
-
154
-
.. code-block:: none
155
-
156
-
[ Upstream commit <sha1> ]
169
+
[ Upstream commit <sha1> ]
157
170
158
171
If the submitted patch deviates from the original upstream patch (for example
159
172
because it had to be adjusted for the older API), this must be very clearly
···
170
191
Review cycle
171
192
------------
172
193
173
-
- When the -stable maintainers decide for a review cycle, the patches will be
174
-
sent to the review committee, and the maintainer of the affected area of
175
-
the patch (unless the submitter is the maintainer of the area) and CC: to
176
-
the linux-kernel mailing list.
177
-
- The review committee has 48 hours in which to ACK or NAK the patch.
178
-
- If the patch is rejected by a member of the committee, or linux-kernel
179
-
members object to the patch, bringing up issues that the maintainers and
180
-
members did not realize, the patch will be dropped from the queue.
181
-
- The ACKed patches will be posted again as part of release candidate (-rc)
182
-
to be tested by developers and testers.
183
-
- Usually only one -rc release is made, however if there are any outstanding
184
-
issues, some patches may be modified or dropped or additional patches may
185
-
be queued. Additional -rc releases are then released and tested until no
186
-
issues are found.
187
-
- Responding to the -rc releases can be done on the mailing list by sending
188
-
a "Tested-by:" email with any testing information desired. The "Tested-by:"
189
-
tags will be collected and added to the release commit.
190
-
- At the end of the review cycle, the new -stable release will be released
191
-
containing all the queued and tested patches.
192
-
- Security patches will be accepted into the -stable tree directly from the
193
-
security kernel team, and not go through the normal review cycle.
194
-
Contact the kernel security team for more details on this procedure.
194
+
- When the -stable maintainers decide for a review cycle, the patches will be
195
+
sent to the review committee, and the maintainer of the affected area of
196
+
the patch (unless the submitter is the maintainer of the area) and CC: to
197
+
the linux-kernel mailing list.
198
+
- The review committee has 48 hours in which to ACK or NAK the patch.
199
+
- If the patch is rejected by a member of the committee, or linux-kernel
200
+
members object to the patch, bringing up issues that the maintainers and
201
+
members did not realize, the patch will be dropped from the queue.
202
+
- The ACKed patches will be posted again as part of release candidate (-rc)
203
+
to be tested by developers and testers.
204
+
- Usually only one -rc release is made, however if there are any outstanding
205
+
issues, some patches may be modified or dropped or additional patches may
206
+
be queued. Additional -rc releases are then released and tested until no
207
+
issues are found.
208
+
- Responding to the -rc releases can be done on the mailing list by sending
209
+
a "Tested-by:" email with any testing information desired. The "Tested-by:"
210
+
tags will be collected and added to the release commit.
211
+
- At the end of the review cycle, the new -stable release will be released
212
+
containing all the queued and tested patches.
213
+
- Security patches will be accepted into the -stable tree directly from the
214
+
security kernel team, and not go through the normal review cycle.
215
+
Contact the kernel security team for more details on this procedure.
195
216
196
217
197
218
Trees
198
219
-----
199
220
200
-
- The queues of patches, for both completed versions and in progress
201
-
versions can be found at:
221
+
- The queues of patches, for both completed versions and in progress
222
+
versions can be found at:
202
223
203
-
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
224
+
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
204
225
205
-
- The finalized and tagged releases of all stable kernels can be found
206
-
in separate branches per version at:
226
+
- The finalized and tagged releases of all stable kernels can be found
227
+
in separate branches per version at:
207
228
208
-
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
229
+
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
209
230
210
-
- The release candidate of all stable kernel versions can be found at:
231
+
- The release candidate of all stable kernel versions can be found at:
211
232
212
-
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
233
+
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
213
234
214
-
.. warning::
215
-
The -stable-rc tree is a snapshot in time of the stable-queue tree and
216
-
will change frequently, hence will be rebased often. It should only be
217
-
used for testing purposes (e.g. to be consumed by CI systems).
235
+
.. warning::
236
+
The -stable-rc tree is a snapshot in time of the stable-queue tree and
237
+
will change frequently, hence will be rebased often. It should only be
238
+
used for testing purposes (e.g. to be consumed by CI systems).
218
239
219
240
220
241
Review committee
221
242
----------------
222
243
223
-
- This is made up of a number of kernel developers who have volunteered for
224
-
this task, and a few that haven't.
244
+
- This is made up of a number of kernel developers who have volunteered for
245
+
this task, and a few that haven't.