[PATCH v1 3/6] docs: 6.Followthrough.rst: interaction with stable wrt to regressions

[Thorsten Leemhuis <linux@leemhuis.info>]

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@leemhuis.info>
---
 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@vger.kernel.org", 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