korg/linux
0
0
Fork 0
mirror of https://mirrors.bfsu.edu.cn/git/linux.git synced 2024-11-28 22:54:05 +08:00
Code Issues Packages Projects Releases Wiki Activity

docs: stable-kernel-rules: move text around to improve flow

Browse Source 
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 <gregkh@linuxfoundation.org>
CC: Sasha Levin <sashal@kernel.org>
CC: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
Link: https://lore.kernel.org/r/16f2377ee40dd7dfa146727fcbe7d1ebccf5b5be.1691219455.git.linux@leemhuis.info
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
Thorsten Leemhuis 2023-08-05 09:21:30 +02:00 committed by Greg Kroah-Hartman
parent 0f11447d9f
commit 3feb21bb0b
1 changed files with 44 additions and 44 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

88
Documentation/process/stable-kernel-rules.rst
View File

@ -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
stable@vger.kernel.org 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
stable@vger.kernel.org. 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: <stable@vger.kernel.org> # 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
stable@vger.kernel.org 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
stable@vger.kernel.org. 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
------------------------