Documentation/process/handling-regressions.rst

191    dangerous way to fix a regression. Don't worry about mainlining a fixed
227  * When receiving reports about regressions in recent stable or longterm kernel
274 with the change, but let all involved parties know about the risk. Hence, make
277 list about the risk, so everyone has the change on the radar in case reports
281 What else is there to known about regressions?
304 More about regression tracking and regzbot
335 duty: they need to tell regzbot about the regression report using the ``#regzbot
341 "Link:" tags to the patch description pointing to all reports about the issue
353 Do I have to tell regzbot about every regression I stumble upon?
359 while. Hence, it's best to tell regzbot about every regression, except when you
383 use regzbot to track severe issues, like reports about hangs, corrupted data,
427    or a ticket in a bug tracker that are slightly related, but about a different
445 Is there more to tell about regzbot and its commands?
448 More detailed and up-to-date information about the Linux
455 Quotes from Linus about regression
488        and simply not have to worry about it.
504        And notice that this is very much about *breaking* peoples environments.
542        about internal kernel API's, and the people who do that then also
552        The rules about regressions have never been about any kind of
555        The rules about regressions are always about "breaks user workflow".
580        The other side of the coin is that people who talk about "API
584        Again, the regression rule is not about documentation, not about
585        API's, and not about the phase of the moon.
587        It's entirely about "we caused problems for user space that used to work".
619        the kernel and never have to worry about it.
664        even care about.
671        upgrade random other tools that I don't even care about as I develop
737        What's instructive about it is that I reverted a commit that wasn't
767        consensus about the issue it exposed.
769        Take-away from the whole thing: it's not about whether you change the
770        kernel-userspace ABI, or fix a bug, or about whether the old code
771        "should never have worked in the first place". It's about whether