From nobody Thu Sep 11 20:39:12 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 02C5BEB64DD for ; Sat, 5 Aug 2023 07:21:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229850AbjHEHVr (ORCPT ); Sat, 5 Aug 2023 03:21:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43764 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229756AbjHEHVj (ORCPT ); Sat, 5 Aug 2023 03:21:39 -0400 Received: from wp530.webpack.hosteurope.de (wp530.webpack.hosteurope.de [80.237.130.52]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBB2C4EC7; Sat, 5 Aug 2023 00:21:37 -0700 (PDT) Received: from ip4d148da6.dynamic.kabel-deutschland.de ([77.20.141.166] helo=truhe.fritz.box); authenticated by wp530.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1qSBbS-0002p2-W0; Sat, 05 Aug 2023 09:21:35 +0200 From: Thorsten Leemhuis To: Greg KH , stable@vger.kernel.org Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Sasha Levin , Jonathan Corbet Subject: [PATCH v1 2/5] docs: stable-kernel-rules: move text around to improve flow Date: Sat, 5 Aug 2023 09:21:30 +0200 Message-Id: <16f2377ee40dd7dfa146727fcbe7d1ebccf5b5be.1691219455.git.linux@leemhuis.info> X-Mailer: git-send-email 2.40.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-bounce-key: webpack.hosteurope.de;linux@leemhuis.info;1691220097;44a1d2ae; X-HE-SMSGID: 1qSBbS-0002p2-W0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" 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 CC: Sasha Levin CC: Jonathan Corbet Signed-off-by: Thorsten Leemhuis --- Documentation/process/stable-kernel-rules.rst | 88 +++++++++---------- 1 file changed, 44 insertions(+), 44 deletions(-) diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/= process/stable-kernel-rules.rst index e68a76abe44b..61b4701d3469 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -41,6 +41,13 @@ Procedure for submitting patches to the -stable tree =20 There are three options to submit a change to -stable trees: =20 +: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 dee= med +worthy at the time it is applied to a public git tree (for instance, becau= se +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: =20 Option 1 @@ -57,50 +64,6 @@ inline comment (see below for details). Once the patch i= s merged it will be applied to the stable tree without anything else needing to be done by the author or subsystem maintainer. =20 -.. _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 dee= med -worthy at the time it is applied to a public git tree (for instance, becau= se -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 co= mmit -text, like this: - -.. code-block:: none - - commit upstream. - -or alternatively: - -.. code-block:: none - - [ Upstream commit ] - Additionally, some patches submitted via :ref:`option_1` may have addition= al patch prerequisites which can be cherry-picked. This can be specified in t= he following format in the sign-off area: @@ -152,6 +115,43 @@ problems: =20 Cc: # see patch description, needs adjustmen= ts for >=3D 6.3 =20 +.. _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 co= mmit +text, like this: + +.. code-block:: none + + commit upstream. + +or alternatively: + +.. code-block:: none + + [ Upstream commit ] + Following the submission ------------------------ =20 --=20 2.40.1