Documentation/process/handling-regressions.rst

27    is optional, but recommended):
125 All this is expected from you and important when it comes to regression, as
129 these tools is regzbot, which heavily relies on the "Link:" tags to associate
145    should be less than two. And it ought to be just a few days, if the issue is
168 On timing once the culprit of a regression is known:
170  * Aim to mainline a fix within two or three days, if the issue is severe or
176    backport); if the culprit became known early during a week and is simple to
181    regression is something people can live with easily for a while -- like a
185    merge window, except when the fix is extraordinarily risky or when the
206    from the mailing list: he is totally fine with that for uncontroversial
210  * In case you are unsure if a fix is worth the risk applying just days before
240    this is especially advisable during merge windows and shortly thereafter, as
248    fix is urgent, make it obvious to ensure others handle it appropriately.
254    of regression fixes. Thus evaluate if skipping linux-next is an option for
257    weekends -- especially when the fix is marked for backporting.
264 How to deal with changes where a risk of regression is known
267 Evaluate how big the risk of regressions is, for example by performing a code
275 sure your patch description makes this aspect obvious. Once the change is
281 What else is there to known about regressions?
293  * how to handle tricky situations, e.g. when a regression is caused by a
308 Why the Linux kernel has a regression tracker, and why is regzbot used?
316 that's why regression tracking is done on a best effort basis.
319 frustrating work, which is why they were abandoned after a while. To prevent
339 For developers there normally is no extra work involved, they just need to make
350 need to be aware of all unfixed regression; to do that, Linus is known to look
369 which regzbot normally sends out once a week on Sunday evening (UTC), which is a
370 few hours before Linus usually publishes new (pre-)releases.
372 What places is regzbot monitoring?
375 Regzbot is watching the most important Linux mailing lists as well as the git
381 The bot is meant to track regressions, hence please don't involve regzbot for
401 One such command is ``#regzbot introduced <version or commit>``, which makes
403 already described above; ``#regzbot ^introduced <version or commit>`` is another
410 or itself is a reply to that mail:
432  * Mark a regression as fixed by a commit that is heading upstream or already
472        The first rule is:
476        and the corollary is that when regressions *do* occur, we admit to
482        is done.
492        work for you, the rule is that it continues to work for you.
498        after it is decades old and nobody uses it with modern kernels any
504        And notice that this is very much about *breaking* peoples environments.
512        see everything they used to see, and so behavior is clearly different,
526        This rule is also not going to change.
528        And yes, I realize that the kernel is "special" in this respect. I'm
561        simply because of a kernel bug" is at all relevant.
563        Now, reality is never entirely black-and-white. So we've had things
565        that may break user space. But even then the rule is that we don't
575        code was in staging or because the man-page said something else) is
576        irrelevant. If staging code is so useful that people end up using it,
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
602        The rule for a regression for the kernel is that some real user
613        And the reason you state for your opinion is in fact exactly *WHY* you
618        The whole point of "we do not regress" is so that people can upgrade
623        That is *ENTIRELY* immaterial.
630        something because we were fixing a bug" is completely insane. We fix
632        we can break something is simply NOT TRUE.
640        How hard is that to understand?
642        Anybody who uses "but it was buggy" as an argument is entirely missing
650        Breaking a user workflow for a "bug" is absolutely the WORST reason
655        is?
657        And without users, your program is not a program, it's a pointless
660        Seriously. This is *why* the #1 rule for kernel development is "we
661        don't break users". Because "I fixed a bug" is absolutely NOT AN
667        other programs at all. It is absolutely required, because flag-days
670        And it is also required simply because I as a kernel developer do not
675        So no. Your rule is COMPLETELY wrong. If you cannot upgrade a kernel
683        Honestly, security people need to understand that "not working" is not
686        Yes, "not working" may be secure. But security in that case is *pointless*.
691        Binary compatibility is more important.
700        I don't understand why this simple logic is so hard for some kernel
733        One _particularly_ last-minute revert is the top-most commit (ignoring
737        What's instructive about it is that I reverted a commit that wasn't
753        The problem was really pre-existing, and it just didn't happen to
775        it's that "first rule of kernel programming", I felt it is perhaps
781    This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
788    is available under CC-BY-4.0, as versions of this text that were processed