Lines Matching +full:never +full:- +full:post +full:- +full:merge +full:- +full:rules
1 .. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
7 *We don't cause regressions* -- this document describes what this "first rule of
9 Documentation/admin-guide/reporting-regressions.rst, which covers the topic from a
10 user's point of view; if you never read that text, go and at least skim over it
21 loop by immediately sending at least a brief "Reply-all" with the list
30 introduced: v5.13..v5.14-rc1``. If not, send a reply (with the regressions
39 #regzbot introduced: v5.13..v5.14-rc1
45 mandated by Documentation/process/submitting-patches.rst and
61 -----------------------------------
72 it into the loop by sending at least a brief "Reply-all" with the list CCed;
79 Documentation/admin-guide/reporting-issues.rst.
88 #regzbot ^introduced: v5.13..v5.14-rc1
91 you can specify a range using commit-ids as well or state a single commit-id
114 remember to do what Documentation/process/submitting-patches.rst,
116 Documentation/process/stable-kernel-rules.rst already explain in more detail:
153 severe or affects many users -- either in general or in prevalent
157 rules of thumb as a guide.
178 bothering many users -- either in general or in prevalent conditions like a
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
199 variant later: that should be straight-forward, as most of the code went
208 tangly. Do the same in precarious or urgent cases -- especially if the
236 mainline as well -- and if that seems likely, take hold of the report. If in
241 mainline; when appropriate thus involve Linus to fast-track the fix (see
247 this is especially advisable during merge windows and shortly thereafter, as
254 Linus, ideally with them being in linux-next at least briefly. Hence, if a
261 of regression fixes. Thus evaluate if skipping linux-next is an option for
264 weekends -- especially when the fix is marked for backporting.
268 ----------------------------------------------------------------
291 Check out Documentation/admin-guide/reporting-regressions.rst, it covers a lot
312 ------------------------------------------
318 Rules like "no regressions" need someone to ensure they are followed, otherwise
354 Torvalds partly rely on regzbot's tracking in their work -- for example when
363 important unexpectedly comes up -- for example a bigger problem in the Linux
372 Check `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_
376 few hours before Linus usually publishes new (pre-)releases.
382 repositories of linux-next, mainline, and stable/longterm.
423 the issue or a fix are discussed -- for example the posting of a patch fixing
432 * Point to a place with further details of interest, like a mailing list post
445 #regzbot dup-of: https://lore.kernel.org/all/[email protected]/
454 More detailed and up-to-date information about the Linux
457 contains a `getting started guide <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_star…
458 and `reference documentation <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_
462 ----------------------------------
467 * From `2017-10-26 (1/2)
480 - we don't cause regressions
490 * From `2017-10-26 (2/2)
549 obviously have to fix up all the in-kernel users of that API. Nobody
555 * From `2020-05-21
556 …<https://lore.kernel.org/all/CAHk-[email protected]/>`…
558 The rules about regressions have never been about any kind of
561 The rules about regressions are always about "breaks user workflow".
569 Now, reality is never entirely black-and-white. So we've had things
581 code was in staging or because the man-page said something else) is
588 any changes to an API you like - as long as nobody notices.
595 * From `2017-11-05
596 …<https://lore.kernel.org/all/CA+55aFzUvbGjD8nQ-+3oiMBx14c_6zOj2n7KLN3UsJ-[email protected]/>`…
598 And our regression rule has never been "behavior doesn't change".
599 That would mean that we could never make any changes at all.
612 * From `2018-08-03
625 the kernel and never have to worry about it.
649 the point. As far as the USER was concerned, it wasn't buggy - it
653 maybe it worked because the user didn't notice - again, it doesn't
673 other programs at all. It is absolutely required, because flag-days
684 * From `2021-06-05
685 …<https://lore.kernel.org/all/CAHk-[email protected]/>`…
694 * From `2011-05-06 (1/3)
695 <https://lore.kernel.org/all/BANLkTim9YvResB+PwRp7QTK-[email protected]/>`_::
700 parse it wrongly - see the fairly recent example of adding uuid's to
717 From `2011-05-06 (2/3)
723 From `2011-05-06 (3/3)
728 …* From `2012-07-06 <https://lore.kernel.org/all/CA+55aFwnLJ+0sjx92EGREGTWOx84wwKaraSzpTNJwPVV8edw8…
736 * From `2019-09-15
737 …<https://lore.kernel.org/lkml/CAHk-[email protected]/>…
739 One _particularly_ last-minute revert is the top-most commit (ignoring
746 improved IO patterns it caused then ended up revealing a user-visible
757 The point here being that we revert based on user-reported _behavior_,
759 The problem was really pre-existing, and it just didn't happen to
764 And never fear, we'll re-introduce the fix that improved on the IO
772 re-introduced (perhaps even backported as a stable patch) once we have
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
785 end-of-content
787 This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
788 of the file. If you want to distribute this text under CC-BY-4.0 only,
791 …rg/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/process/handling-regressions.rst
794 is available under CC-BY-4.0, as versions of this text that were processed