Thorsten Leemhuis <linux@xxxxxxxxxxxxx> writes: > 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_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@xxxxxxxxxxxxxx/ [1] > Signed-off-by: Thorsten Leemhuis <linux@xxxxxxxxxxxxx> > --- > 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. I'm not quite sure what "tangly" or "precarious" means in this case? > + - 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 s/usual/appropriate/ ? That's all. jon
