Add a few notes on the appropriate tags to be used in changes that fix
regressions.
This removes equivalent paragraphs from a section in
Documentation/process/handling-regressions.rst, which will become mostly
obsolete through this and follow-up changes.
Signed-off-by: Thorsten Leemhuis <linux@xxxxxxxxxxxxx>
---
Note:
* Not sure if the "add a second Fixes: tag for the change that exposed
an earlier problem" is appropriate, but it results in the most
reliable solution without much overhead.
* On a brief look it might seem like this changes the "participation in
stable is optional for mainline developers" approach. But that is not
the case, as the point is just kindly asking developers to take care
of stable inclusion.
---
Documentation/process/6.Followthrough.rst | 16 ++++++++++++++++
Documentation/process/handling-regressions.rst | 7 -------
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/Documentation/process/6.Followthrough.rst b/Documentation/process/6.Followthrough.rst
index 763a80d21240f0..2ba16a71aba9b4 100644
--- a/Documentation/process/6.Followthrough.rst
+++ b/Documentation/process/6.Followthrough.rst
@@ -234,6 +234,22 @@ On procedure:
requests again should ideally come directly from maintainers or happen in
accordance with them.
+On tags in the patch description of regressions fixes:
+
+ - Include the tags Documentation/process/5.Posting.rst mentions for
+ regressions; this usually means a "Reported-by:" tag followed by "Link:" or
+ "Closes:" tag pointing to the report as well as a "Fixes:" tag; if it's a
+ regression a later change exposed, add a "Fixes:" tag for that one, too.
+
+ - Did the culprit make it into a proper mainline release during the past
+ twelve months? Or is it a recent mainline commit backported to stable or
+ longterm releases in the past few weeks? Then you are kindly asked to ensure
+ stable inclusion as described by Documentation/process/stable-kernel-rules.rst.
+ Usually you want to realized thos by adding a "Cc: stable@xxxxxxxxxxxxxxx" to
+ the patch description. Note, a "Fixes:" tag alone does not guarantee a
+ backport, as the stable team does not pick up all such changes and might
+ silently drop them in case trouble arises.
+
Regarding stable and longterm series:
- You are free to leave handling regressions to the stable team if the problem
diff --git a/Documentation/process/handling-regressions.rst b/Documentation/process/handling-regressions.rst
index cfb44a9928d450..da53e12fc6d96c 100644
--- a/Documentation/process/handling-regressions.rst
+++ b/Documentation/process/handling-regressions.rst
@@ -196,13 +196,6 @@ On procedure:
regressions to be handled like those from the current cycle, unless fixing
bears unusual risks.
-Regarding stable and longterm kernels:
-
- * If a regression made it into a proper mainline release during the past
- twelve months, ensure to tag the fix with "Cc: stable@xxxxxxxxxxxxxxx", as a
- "Fixes:" tag alone does not guarantee a backport. Please add the same tag,
- in case you know the culprit was backported to stable or longterm kernels.
-
On patch flow:
* Developers, when trying to reach the time periods mentioned above, remember
--
2.45.0
