Lines Matching +full:eye +full:- +full:term
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
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
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
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
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 ------------------------------------------
321 keep an eye on things as the Linux kernel's regression tracker, who's
328 with the long term goal to automate regression tracking as much as possible for
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
445 #regzbot dup-of: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/
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-=wiVi7mSrsMP=fLXQrXK_UimybW=ziLOwSzFTtoXUacWVQ@mail.gmail.com/>`…
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-qsd4Dcw@mail.gmail.com/>`…
612 * From `2018-08-03
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-=wiUVqHN76YUwhkjZzwTdjMMJf_zN4+u7vEJjmEGh3recw@mail.gmail.com/>`…
694 * From `2011-05-06 (1/3)
695 <https://lore.kernel.org/all/BANLkTim9YvResB+PwRp7QTK-a5VNg2PvmQ@mail.gmail.com/>`_::
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-=wiP4K8DRJWsCo=20hn_6054xBamGKF2kPgUzpB5aMaofA@mail.gmail.com/>…
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
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