Documentation/process/handling-regressions.rst

27    is optional, but recommended):
132 All this is expected from you and important when it comes to regression, as
136 these tools is regzbot, which heavily relies on the "Closes:" tags to associate
152    should be less than two. And it ought to be just a few days, if the issue is
175 On timing once the culprit of a regression is known:
177  * Aim to mainline a fix within two or three days, if the issue is severe or
183    backport); if the culprit became known early during a week and is simple to
188    regression is something people can live with easily for a while -- like a
192    merge window, except when the fix is extraordinarily risky or when the
213    from the mailing list: he is totally fine with that for uncontroversial
217  * In case you are unsure if a fix is worth the risk applying just days before
247    this is especially advisable during merge windows and shortly thereafter, as
255    fix is urgent, make it obvious to ensure others handle it appropriately.
261    of regression fixes. Thus evaluate if skipping linux-next is an option for
264    weekends -- especially when the fix is marked for backporting.
271 How to deal with changes where a risk of regression is known
274 Evaluate how big the risk of regressions is, for example by performing a code
282 sure your patch description makes this aspect obvious. Once the change is
288 What else is there to known about regressions?
300  * how to handle tricky situations, e.g. when a regression is caused by a
315 Why the Linux kernel has a regression tracker, and why is regzbot used?
323 that's why regression tracking is done on a best effort basis.
326 frustrating work, which is why they were abandoned after a while. To prevent
346 For developers there normally is no extra work involved, they just need to make
356 need to be aware of all unfixed regression; to do that, Linus is known to look
375 which regzbot normally sends out once a week on Sunday evening (UTC), which is a
376 few hours before Linus usually publishes new (pre-)releases.
378 What places is regzbot monitoring?
381 Regzbot is watching the most important Linux mailing lists as well as the git
387 The bot is meant to track regressions, hence please don't involve regzbot for
407 One such command is ``#regzbot introduced: <version or commit>``, which makes
409 already described above; ``#regzbot ^introduced: <version or commit>`` is another
416 or itself is a reply to that mail:
438  * Mark a regression as fixed by a commit that is heading upstream or already
478        The first rule is:
482        and the corollary is that when regressions *do* occur, we admit to
488        is done.
498        work for you, the rule is that it continues to work for you.
504        after it is decades old and nobody uses it with modern kernels any
510        And notice that this is very much about *breaking* peoples environments.
518        see everything they used to see, and so behavior is clearly different,
532        This rule is also not going to change.
534        And yes, I realize that the kernel is "special" in this respect. I'm
567        simply because of a kernel bug" is at all relevant.
569        Now, reality is never entirely black-and-white. So we've had things
571        that may break user space. But even then the rule is that we don't
581        code was in staging or because the man-page said something else) is
582        irrelevant. If staging code is so useful that people end up using it,
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
608        The rule for a regression for the kernel is that some real user
619        And the reason you state for your opinion is in fact exactly *WHY* you
624        The whole point of "we do not regress" is so that people can upgrade
629        That is *ENTIRELY* immaterial.
636        something because we were fixing a bug" is completely insane. We fix
638        we can break something is simply NOT TRUE.
646        How hard is that to understand?
648        Anybody who uses "but it was buggy" as an argument is entirely missing
656        Breaking a user workflow for a "bug" is absolutely the WORST reason
661        is?
663        And without users, your program is not a program, it's a pointless
666        Seriously. This is *why* the #1 rule for kernel development is "we
667        don't break users". Because "I fixed a bug" is absolutely NOT AN
673        other programs at all. It is absolutely required, because flag-days
676        And it is also required simply because I as a kernel developer do not
681        So no. Your rule is COMPLETELY wrong. If you cannot upgrade a kernel
689        Honestly, security people need to understand that "not working" is not
692        Yes, "not working" may be secure. But security in that case is *pointless*.
697        Binary compatibility is more important.
706        I don't understand why this simple logic is so hard for some kernel
739        One _particularly_ last-minute revert is the top-most commit (ignoring
743        What's instructive about it is that I reverted a commit that wasn't
759        The problem was really pre-existing, and it just didn't happen to
781        it's that "first rule of kernel programming", I felt it is perhaps
787    This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
794    is available under CC-BY-4.0, as versions of this text that were processed