Skip to content

Commit 5db34f5

Browse files
knurdJonathan Corbet
knurd
authored and
Jonathan Corbet
committed
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
1 parent 2263c40 commit 5db34f5

1 file changed

Lines changed: 102 additions & 123 deletions

File tree

‎Documentation/process/stable-kernel-rules.rst‎

Lines changed: 102 additions & 123 deletions
Original file line numberDiff line numberDiff line change
@@ -6,29 +6,29 @@ Everything you ever wanted to know about Linux -stable releases
66
Rules on what kind of patches are accepted, and which ones are not, into the
77
"-stable" tree:
88

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-
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).
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+
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).
3232

3333

3434
Procedure for submitting patches to the -stable tree
@@ -42,11 +42,11 @@ Procedure for submitting patches to the -stable tree
4242

4343
There are three options to submit a change to -stable trees:
4444

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.
5050

5151
The sections below describe each of the options in more detail.
5252

@@ -68,79 +68,62 @@ Option 1
6868
********
6969

7070
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::
7272

73-
.. code-block:: none
73+
Cc: stable@vger.kernel.org
7474

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.
8077

8178
To sent additional instructions to the stable team, use a shell-style inline
8279
comment to pass arbitrary or predefined notes:
8380

84-
* Specify any additional patch prerequisites for cherry picking:
85-
86-
.. code-block:: none
87-
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>
93-
94-
The tag sequence has the meaning of:
95-
96-
.. code-block:: none
81+
* Specify any additional patch prerequisites for cherry picking::
9782

98-
git cherry-pick a1f84a3
99-
git cherry-pick 1b9508f
100-
git cherry-pick fd21073
101-
git cherry-pick <this commit>
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>
10288

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:
89+
The tag sequence has the meaning of::
10690

107-
.. code-block:: none
91+
git cherry-pick a1f84a3
92+
git cherry-pick 1b9508f
93+
git cherry-pick fd21073
94+
git cherry-pick <this commit>
10895

109-
patch1
110-
patch2
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::
11199

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.
100+
patch1
101+
patch2
115102

116-
* Point out kernel version prerequisites:
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.
117106

118-
.. code-block:: none
107+
* Point out kernel version prerequisites::
119108

120-
Cc: <stable@vger.kernel.org> # 3.3.x
109+
Cc: <stable@vger.kernel.org> # 3.3.x
121110

122-
The tag has the meaning of:
111+
The tag has the meaning of::
123112

124-
.. code-block:: none
113+
git cherry-pick <this commit>
125114

126-
git cherry-pick <this commit>
115+
For each "-stable" tree starting with the specified version.
127116

128-
For each "-stable" tree starting with the specified version.
117+
Note, such tagging is unnecessary if the stable team can derive the
118+
appropriate versions from Fixes: tags.
129119

130-
Note, such tagging is unnecessary if the stable team can derive the
131-
appropriate versions from Fixes: tags.
120+
* Delay pick up of patches::
132121

133-
* Delay pick up of patches:
122+
Cc: <stable@vger.kernel.org> # after -rc3
134123

135-
.. code-block:: none
124+
* Point out known problems::
136125

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
144127

145128
.. _option_2:
146129

@@ -160,17 +143,13 @@ Option 3
160143
Send the patch, after verifying that it follows the above rules, to
161144
stable@vger.kernel.org and mention the kernel versions you wish it to be applied
162145
to. When doing so, you must note the upstream commit ID in the changelog of your
163-
submission with a separate line above the commit text, like this:
164-
165-
.. code-block:: none
166-
167-
commit <sha1> upstream.
146+
submission with a separate line above the commit text, like this::
168147

169-
or alternatively:
148+
commit <sha1> upstream.
170149

171-
.. code-block:: none
150+
Or alternatively::
172151

173-
[ Upstream commit <sha1> ]
152+
[ Upstream commit <sha1> ]
174153

175154
If the submitted patch deviates from the original upstream patch (for example
176155
because it had to be adjusted for the older API), this must be very clearly
@@ -191,55 +170,55 @@ developers and by the relevant subsystem maintainer.
191170
Review cycle
192171
------------
193172

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.
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.
216195

217196

218197
Trees
219198
-----
220199

221-
- The queues of patches, for both completed versions and in progress
222-
versions can be found at:
200+
- The queues of patches, for both completed versions and in progress
201+
versions can be found at:
223202

224-
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
203+
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
225204

226-
- The finalized and tagged releases of all stable kernels can be found
227-
in separate branches per version at:
205+
- The finalized and tagged releases of all stable kernels can be found
206+
in separate branches per version at:
228207

229-
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
208+
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
230209

231-
- The release candidate of all stable kernel versions can be found at:
210+
- The release candidate of all stable kernel versions can be found at:
232211

233-
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
212+
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
234213

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).
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).
239218

240219

241220
Review committee
242221
----------------
243222

244-
- This is made up of a number of kernel developers who have volunteered for
245-
this task, and a few that haven't.
223+
- This is made up of a number of kernel developers who have volunteered for
224+
this task, and a few that haven't.

0 commit comments

Comments
 (0)