[PATCH v1 6/6] docs: 6.Followthrough.rst: advice on handling regressions fixes

[Thorsten Leemhuis <linux@leemhuis.info>]

Add some advice on how to handle regressions as developer, reviewer, and
maintainer, as resolving regression without unnecessary delays requires
multiple people working hand in hand.

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     | 24 ++++++++++++++++---
 .../process/handling-regressions.rst          | 16 -------------
 2 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/Documentation/process/6.Followthrough.rst b/Documentation/process/6.Followthrough.rst
index 587e80578f83a9..8ffa3cd142e8a0 100644
--- a/Documentation/process/6.Followthrough.rst
+++ b/Documentation/process/6.Followthrough.rst
@@ -198,6 +198,11 @@ maintainers and other developers will take note if you fail to handle regression
 appropriately, especially if they then have to fix the problem themselves: this
 could well make it harder for you to incorporate future changes.
 
+In general:
+
+ - Prioritize work on providing, reviewing, and mainlining regression fixes over
+   other upstream Linux kernel work.
+
 On timing once the mainline change causing the regression became known:
 
  - If the regression is severe or reported by many people within a short
@@ -229,9 +234,22 @@ On timing once the mainline change causing the regression became known:
 
 On procedure:
 
- - Regression fixes are not required to spend time in linux-next, but depending
-   on the fix and the alignment with pull requests it might be beneficial to
-   have them in there for a day or two.
+ - Developers, when trying to reach the time periods mentioned above, remember
+   to account for the time it will take to test, review, commit, and mainline
+   fixes, ideally with them being in linux-next briefly.  To achieve that, make
+   the appropriate urgency of a fix obvious in the submission and consider
+   opting for a revert to be on the safe side.
+
+ - Reviewers, you are kindly asked to prefer reviewing regression fixes over
+   other changes.
+
+ - Maintainers, you likewise are kindly asked to expedite the handling of
+   regression fixes.  They for example are not required to spend time in
+   linux-next, but depending on the fix and the alignment with pull requests it
+   might be beneficial to have them in there for a day or two.  When appropriate,
+   also consider sending an additional pull request.  Furthermore try to avoid
+   holding onto regression fixes over weekends -- especially when some are
+   marked for backporting to stable series.
 
  - If a regression seems tangly, precarious, or urgent, consider CCing Linus on
    discussions and patch reviews; do the same if the responsible maintainers
diff --git a/Documentation/process/handling-regressions.rst b/Documentation/process/handling-regressions.rst
index 581f99675a9d52..7b8f0b122c1552 100644
--- a/Documentation/process/handling-regressions.rst
+++ b/Documentation/process/handling-regressions.rst
@@ -156,22 +156,6 @@ only these options:
 How to realize that in practice depends on various factors. Use the rules of
 thumb outlined in Documentation/process/6.Followthrough.rst as a guide.
 
-On patch flow:
-
- * Developers, when trying to reach the time periods mentioned above, remember
-   to account for the time it takes to get fixes tested, reviewed, and merged by
-   Linus, ideally with them being in linux-next at least briefly. Hence, if a
-   fix is urgent, make it obvious to ensure others handle it appropriately.
-
- * Reviewers, you are kindly asked to assist developers in reaching the time
-   periods mentioned above by reviewing regression fixes in a timely manner.
-
- * Subsystem maintainers, you likewise are encouraged to expedite the handling
-   of regression fixes. Thus evaluate if skipping linux-next is an option for
-   the particular fix. Also consider sending git pull requests more often than
-   usual when needed. And try to avoid holding onto regression fixes over
-   weekends -- especially when the fix is marked for backporting.
-
 
 More aspects regarding regressions developers should be aware of
 ----------------------------------------------------------------
-- 
2.45.0