Documentation/process/handling-regressions.rst

198    dangerous way to fix a regression. Don't worry about mainlining a fixed
234  * When receiving reports about regressions in recent stable or longterm kernel
281 with the change, but let all involved parties know about the risk. Hence, make
284 list about the risk, so everyone has the change on the radar in case reports
288 What else is there to known about regressions?
311 More about regression tracking and regzbot
342 duty: they need to tell regzbot about the regression report using the ``#regzbot
348 links to the patch description pointing to all reports about the issue fixed.
359 Do I have to tell regzbot about every regression I stumble upon?
365 while. Hence, it's best to tell regzbot about every regression, except when you
389 use regzbot to track severe issues, like reports about hangs, corrupted data,
433    or a ticket in a bug tracker that are slightly related, but about a different
451 Is there more to tell about regzbot and its commands?
454 More detailed and up-to-date information about the Linux
461 Quotes from Linus about regression
494        and simply not have to worry about it.
510        And notice that this is very much about *breaking* peoples environments.
548        about internal kernel API's, and the people who do that then also
558        The rules about regressions have never been about any kind of
561        The rules about regressions are always about "breaks user workflow".
586        The other side of the coin is that people who talk about "API
590        Again, the regression rule is not about documentation, not about
591        API's, and not about the phase of the moon.
593        It's entirely about "we caused problems for user space that used to work".
625        the kernel and never have to worry about it.
670        even care about.
677        upgrade random other tools that I don't even care about as I develop
743        What's instructive about it is that I reverted a commit that wasn't
773        consensus about the issue it exposed.
775        Take-away from the whole thing: it's not about whether you change the
776        kernel-userspace ABI, or fix a bug, or about whether the old code
777        "should never have worked in the first place". It's about whether