Add a few notes on how the interaction with the stable team works when
it comes to mainline regressions that also affect stable series.
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>
---
Documentation/process/6.Followthrough.rst | 22 +++++++++++++++++++
.../process/handling-regressions.rst | 19 ----------------
2 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/Documentation/process/6.Followthrough.rst b/Documentation/process/6.Followthrough.rst
index f9ae3a86ee0c49..763a80d21240f0 100644
--- a/Documentation/process/6.Followthrough.rst
+++ b/Documentation/process/6.Followthrough.rst
@@ -234,6 +234,28 @@ On procedure:
requests again should ideally come directly from maintainers or happen in
accordance with them.
+Regarding stable and longterm series:
+
+ - You are free to leave handling regressions to the stable team if the problem
+ at no point in time occurred with mainline or was fixed there already.
+
+ - When receiving reports about regressions in recent stable or longterm kernel
+ series, consider evaluating at least briefly if the issue might happen in
+ current mainline as well -- and if that seems likely, take hold of the
+ report. If in doubt, ask the reporter to check mainline.
+
+ - Fix regressions quickly in mainline, whenever you want to swiftly resolve one
+ that recently made it into a mainline, stable, or longterm release; in urgent
+ cases hence involve Linus to fast-track fixes (see above). This route is
+ required, as the stable team normally does neither revert nor fix any changes
+ in their trees, as long as they cause the same problem in mainline.
+
+ - In case of urgent fixes for regression affecting a recent mainline, stable,
+ or longterm release, you might want to ensure prompt backporting by dropping
+ the stable team a note once the fix was mainlined; this is especially
+ advisable during merge windows and shortly thereafter, as the fix otherwise
+ might land at the end of a huge patch queue.
+
Other things that can happen
-----------------------------
diff --git a/Documentation/process/handling-regressions.rst b/Documentation/process/handling-regressions.rst
index c020418499f6a2..cfb44a9928d450 100644
--- a/Documentation/process/handling-regressions.rst
+++ b/Documentation/process/handling-regressions.rst
@@ -198,30 +198,11 @@ On procedure:
Regarding stable and longterm kernels:
- * You are free to leave regressions to the stable team, if they at no point in
- time occurred with mainline or were fixed there already.
-
* 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.
- * When receiving reports about regressions in recent stable or longterm kernel
- series, please evaluate at least briefly if the issue might happen in current
- mainline as well -- and if that seems likely, take hold of the report. If in
- doubt, ask the reporter to check mainline.
-
- * Whenever you want to swiftly resolve a regression that recently also made it
- into a proper mainline, stable, or longterm release, fix it quickly in
- mainline; when appropriate thus involve Linus to fast-track the fix (see
- above). That's because the stable team normally does neither revert nor fix
- any changes that cause the same problems in mainline.
-
- * In case of urgent regression fixes you might want to ensure prompt
- backporting by dropping the stable team a note once the fix was mainlined;
- this is especially advisable during merge windows and shortly thereafter, as
- the fix otherwise might land at the end of a huge patch queue.
-
On patch flow:
* Developers, when trying to reach the time periods mentioned above, remember
--
2.45.0
