Add a few notes on when to involve Linus in regressions. Part of this spells out slightly obvious things infrequent developers might not be aware of, while others are based on a recent statement from Linus[1].
This removes equivalent paragraphs from a section in Documentation/process/handling-regressions.rst, which will become mostly obsolete through this and follow-up changes. Link: https://lore.kernel.org/all/CAHk-=wis_qqy4odnynnki5b7qhosmxtoj1jxo5wmb6sruwq...@mail.gmail.com/ [1] Signed-off-by: Thorsten Leemhuis <li...@leemhuis.info> --- Documentation/process/6.Followthrough.rst | 17 +++++++++++++++++ Documentation/process/handling-regressions.rst | 17 ----------------- 2 files changed, 17 insertions(+), 17 deletions(-) diff --git a/Documentation/process/6.Followthrough.rst b/Documentation/process/6.Followthrough.rst index ed5e32348f2403..f9ae3a86ee0c49 100644 --- a/Documentation/process/6.Followthrough.rst +++ b/Documentation/process/6.Followthrough.rst @@ -217,6 +217,23 @@ On procedure: on the fix and the alignment with pull requests it might be beneficial to have them in there for a day or two. + - If a regression seems tangly, precarious, or urgent, consider CCing Linus on + discussions and patch reviews; do the same if the responsible maintainers + are suspected to be unavailable. + + - For urgent fixes, consider asking Linus to pick them up straight from the + mailing list: he is totally fine with that for occasional and uncontroversial + fixes. Such requests should ideally come directly from maintainers or happen + in accordance with them. + + - In case you are unsure if a fix is worth the risk applying just days before + a new mainline release, send Linus a mail with the usual lists, developers, + and maintainers in CC; in it, summarize the situation while asking him to + consider picking up the fix straight from the list as he sees fit. Linus + then can make the call and when appropriate even postpone the release. Such + requests again should ideally come directly from maintainers or happen in + accordance with them. + Other things that can happen ----------------------------- diff --git a/Documentation/process/handling-regressions.rst b/Documentation/process/handling-regressions.rst index 62ecc5c5c0765f..c020418499f6a2 100644 --- a/Documentation/process/handling-regressions.rst +++ b/Documentation/process/handling-regressions.rst @@ -196,23 +196,6 @@ On procedure: regressions to be handled like those from the current cycle, unless fixing bears unusual risks. - * Consider CCing Linus on discussions or patch review, if a regression seems - tangly. Do the same in precarious or urgent cases -- especially if the - subsystem maintainer might be unavailable. Also CC the stable team, when you - know such a regression made it into a mainline, stable, or longterm release. - - * For urgent regressions, consider asking Linus to pick up the fix straight - from the mailing list: he is totally fine with that for uncontroversial - fixes. Ideally though such requests should happen in accordance with the - subsystem maintainers or come directly from them. - - * In case you are unsure if a fix is worth the risk applying just days before - a new mainline release, send Linus a mail with the usual lists and people in - CC; in it, summarize the situation while asking him to consider picking up - the fix straight from the list. He then himself can make the call and when - needed even postpone the release. Such requests again should ideally happen - in accordance with the subsystem maintainers or come directly from them. - Regarding stable and longterm kernels: * You are free to leave regressions to the stable team, if they at no point in -- 2.45.0
