[PATCH v2 0/2] docs: stable-kernel-rules: add delayed backporting option and a few tweaks
I only set down to create the first of the two patches. But while doing so I noticed a few things that seemed odd for me with my background on writing and editing texts. So I just quickly performed a few additional changes to fix those to see if the stable team would appreciate them, as this document is clearly their domain.
v2: [this mail] * a few small tweaks after feedback from v1 submission * drop patch 3 for now * drop RFC
v1: https://lore.kernel.org/linux-doc/d30686781c47c83927e0a41f6a1167a679fa822c.1...
Thorsten Leemhuis (2): docs: stable-kernel-rules: mention other usages for stable tag comments docs: stable-kernel-rules: make rule section more straight forward
Documentation/process/stable-kernel-rules.rst | 60 ++++++++++++------- 1 file changed, 37 insertions(+), 23 deletions(-)
base-commit: 016571b6d52deb473676fb4d24baf8ed3667ae21
Document how to delay backporting or send a note to the stable team using shell-style inline comments attached to stable tags.
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 --- v1-v2: * change a ";" into a "." --- Documentation/process/stable-kernel-rules.rst | 22 ++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 51df1197d5ab..de0046c0586b 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -55,9 +55,10 @@ To have the patch automatically included in the stable tree, add the tag
Cc: stable@vger.kernel.org
-in the sign-off area. 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. +in the sign-off area. To accompany a note to the stable team, use a shell-style +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:
@@ -139,6 +140,21 @@ The tag has the meaning of:
For each "-stable" tree starting with the specified version.
+To delay pick up of patches submitted via :ref:`option_1`, use the following +format: + +.. code-block:: none + + Cc: stable@vger.kernel.org # after 4 weeks in mainline + +For any other requests related to patches submitted via :ref:`option_1`, just +add a note to the stable tag. This for example can be used to point out known +problems: + +.. code-block:: none + + Cc: stable@vger.kernel.org # see patch description, needs adjustments for >= 6.3 + Following the submission:
- The sender will receive an ACK when the patch has been accepted into the
Tweak some of the rule text to make things more straight forward, with the goal to stick closely to the intend of the old text:
* put the "it or equivalent fix must be upstream" rule at the top, as it's one of the most important ones that at the same time often seems to be missed by developers. * "It must fix only one thing" was dropped, as that is almost always a thing that needs to be handled earlier when the change is mainlined. Furthermore, this is already indirectly covered by the "Separate your changes" section in Documentation/process/submitting-patches.rst which the rules already point to. * six other rules are in the end one rule with clarifications; structure the text accordingly to make it a lot easier to follow and understand the intend. * drop the 'In short, something critical' from one of those notes: it contradicts the "real bug that bothers people" aspect somewhat and does not really add anything
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 --- v1->v2: - also drop the 'In short, something critical' --- Documentation/process/stable-kernel-rules.rst | 38 +++++++++---------- 1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index de0046c0586b..d3f040c2738e 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -6,31 +6,29 @@ Everything you ever wanted to know about Linux -stable releases Rules on what kind of patches are accepted, and which ones are not, into the "-stable" tree:
+ - It or an equivalent fix must already exist in Linus' tree (upstream). - It must be obviously correct and tested. - It cannot be bigger than 100 lines, with context. - - It must fix only one thing. - - It must fix a real bug that bothers people (not a, "This could be a - problem..." type thing). - - It must fix a problem that causes a build error (but not for things - marked CONFIG_BROKEN), an oops, a hang, data corruption, a real - security issue, or some "oh, that's not good" issue. In short, something - critical. - - Serious issues as reported by a user of a distribution kernel may also - be considered if they fix a notable performance or interactivity issue. - As these fixes are not as obvious and have a higher risk of a subtle - regression they should only be submitted by a distribution kernel - maintainer and include an addendum linking to a bugzilla entry if it - exists and additional information on the user-visible impact. - - New device IDs and quirks are also accepted. - - No "theoretical race condition" issues, unless an explanation of how the - race can be exploited is also provided. - - It cannot contain any "trivial" fixes in it (spelling changes, - whitespace cleanups, etc). - It must follow the :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` rules. - - It or an equivalent fix must already exist in Linus' tree (upstream). - + - It must either fix a real bug that bothers people or just add a device ID. + To elaborate on the former: + + - It fixes a problem like an oops, a hang, data corruption, a real security + issue, a hardware quirk, a build error (but not for things marked + CONFIG_BROKEN), or some "oh, that's not good" issue. + - Serious issues as reported by a user of a distribution kernel may also + be considered if they fix a notable performance or interactivity issue. + As these fixes are not as obvious and have a higher risk of a subtle + regression they should only be submitted by a distribution kernel + maintainer and include an addendum linking to a bugzilla entry if it + exists and additional information on the user-visible impact. + - No "This could be a problem..." type of things like a "theoretical race + condition", unless an explanation of how the bug can be exploited is also + provided. + - No "trivial" fixes without benefit for users (spelling changes, whitespace + cleanups, etc).
Procedure for submitting patches to the -stable tree ----------------------------------------------------
linux-stable-mirror@lists.linaro.org
-
Thorsten Leemhuis