forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs: stable-kernel-rules: move text around to improve flow
Move the short description about when to use which of the submission options to the top of the section, as it currently sits somewhat odd in the middle between option 3 and examples of option 1. Also move the examples of Option 1 into the section describing it (which in the diff looks like option 2 and 3 are moving down). No text changes, just moving it around. CC: Greg KH <[email protected]> CC: Sasha Levin <[email protected]> CC: Jonathan Corbet <[email protected]> Signed-off-by: Thorsten Leemhuis <[email protected]> Link: https://lore.kernel.org/r/16f2377ee40dd7dfa146727fcbe7d1ebccf5b5be.1691219455.git.linux@leemhuis.info Signed-off-by: Greg Kroah-Hartman <[email protected]>
- Loading branch information
Showing
1 changed file
with
44 additions
and
44 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -41,6 +41,13 @@ Procedure for submitting patches to the -stable tree | |
|
||
There are three options to submit a change to -stable trees: | ||
|
||
:ref:`option_1` is **strongly** preferred, is the easiest and most common. | ||
:ref:`option_2` and :ref:`option_3` are more useful if the patch isn't deemed | ||
worthy at the time it is applied to a public git tree (for instance, because | ||
it deserves more regression testing first). :ref:`option_3` is especially | ||
useful if the original upstream patch needs to be backported (for example | ||
the backport needs some special handling due to e.g. API changes). | ||
|
||
.. _option_1: | ||
|
||
Option 1 | ||
|
@@ -57,50 +64,6 @@ inline comment (see below for details). Once the patch is merged it will be | |
applied to the stable tree without anything else needing to be done by the | ||
author or subsystem maintainer. | ||
|
||
.. _option_2: | ||
|
||
Option 2 | ||
******** | ||
|
||
After the patch has been merged to Linus' tree, send an email to | ||
[email protected] containing the subject of the patch, the commit ID, | ||
why you think it should be applied, and what kernel version you wish it to | ||
be applied to. | ||
|
||
.. _option_3: | ||
|
||
Option 3 | ||
******** | ||
|
||
Send the patch, after verifying that it follows the above rules, to | ||
[email protected]. You must note the upstream commit ID in the | ||
changelog of your submission, as well as the kernel version you wish | ||
it to be applied to. | ||
|
||
:ref:`option_1` is **strongly** preferred, is the easiest and most common. | ||
:ref:`option_2` and :ref:`option_3` are more useful if the patch isn't deemed | ||
worthy at the time it is applied to a public git tree (for instance, because | ||
it deserves more regression testing first). :ref:`option_3` is especially | ||
useful if the original upstream patch needs to be backported (for example | ||
the backport needs some special handling due to e.g. API changes). | ||
|
||
Note that for :ref:`option_3`, if the patch deviates from the original | ||
upstream patch (for example because it had to be backported) this must be very | ||
clearly documented and justified in the patch description. | ||
|
||
The upstream commit ID must be specified with a separate line above the commit | ||
text, like this: | ||
|
||
.. code-block:: none | ||
commit <sha1> upstream. | ||
or alternatively: | ||
|
||
.. code-block:: none | ||
[ Upstream commit <sha1> ] | ||
Additionally, some patches submitted via :ref:`option_1` may have additional | ||
patch prerequisites which can be cherry-picked. This can be specified in the | ||
following format in the sign-off area: | ||
|
@@ -152,6 +115,43 @@ problems: | |
Cc: <[email protected]> # see patch description, needs adjustments for >= 6.3 | ||
.. _option_2: | ||
|
||
Option 2 | ||
******** | ||
|
||
After the patch has been merged to Linus' tree, send an email to | ||
[email protected] containing the subject of the patch, the commit ID, | ||
why you think it should be applied, and what kernel version you wish it to | ||
be applied to. | ||
|
||
.. _option_3: | ||
|
||
Option 3 | ||
******** | ||
|
||
Send the patch, after verifying that it follows the above rules, to | ||
[email protected]. You must note the upstream commit ID in the | ||
changelog of your submission, as well as the kernel version you wish | ||
it to be applied to. | ||
|
||
Note that for :ref:`option_3`, if the patch deviates from the original | ||
upstream patch (for example because it had to be backported) this must be very | ||
clearly documented and justified in the patch description. | ||
|
||
The upstream commit ID must be specified with a separate line above the commit | ||
text, like this: | ||
|
||
.. code-block:: none | ||
commit <sha1> upstream. | ||
or alternatively: | ||
|
||
.. code-block:: none | ||
[ Upstream commit <sha1> ] | ||
Following the submission | ||
------------------------ | ||
|
||
|