Lines Matching +full:1234567890 +full:a
9 Documentation/admin-guide/reporting-regressions.rst, which covers the topic from a
20 * When receiving a mailed report that did not CC the list, bring it into the
21 loop by immediately sending at least a brief "Reply-all" with the list
29 * For mailed reports, check if the reporter included a line like ``#regzbot
30 introduced: v5.13..v5.14-rc1``. If not, send a reply (with the regressions
31 list in CC) containing a paragraph like the following, which tells regzbot
36 * When forwarding reports from a bug tracker to the regressions list (see
37 above), include a paragraph like the following::
71 * When you receive a report by mail that did not CC the list, immediately bring
72 it into the loop by sending at least a brief "Reply-all" with the list CCed;
73 try to ensure it gets CCed again in case you reply to a reply that omitted
76 * If a report submitted in a bug tracker hits your Inbox, forward or bounce it
84 * For mailed reports, check if the reporter included a "regzbot command" like
85 ``#regzbot introduced: 1f2e3d4c5b6a``. If not, send a reply (with the
86 regressions list in CC) with a paragraph like the following:::
91 you can specify a range using commit-ids as well or state a single commit-id
100 * When forwarding a regression reported to a bug tracker, include a paragraph
121 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=1234567890
127 * Add a "Fixes:" tag to specify the commit causing the regression.
142 As a Linux kernel developer, you are expected to give your best to prevent
143 situations where a regression caused by a recent change of yours leaves users
146 * Run a kernel with a regression that impacts usage.
152 should be less than two. And it ought to be just a few days, if the issue is
157 rules of thumb as a guide.
162 latter concerns a severe issue (e.g. acute security vulnerability, data loss,
165 * Expedite fixing mainline regressions that recently made it into a proper
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
178 bothering many users -- either in general or in prevalent conditions like a
181 * Aim to mainline a fix by Sunday after the next, if the culprit made it
182 into a recent mainline, stable, or longterm release (either directly or via
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
193 culprit was mainlined more than a year ago.
198 dangerous way to fix a regression. Don't worry about mainlining a fixed
207 * Consider CCing Linus on discussions or patch review, if a regression seems
210 know such a regression made it into a mainline, stable, or longterm release.
217 * In case you are unsure if a fix is worth the risk applying just days before
218 a new mainline release, send Linus a mail with the usual lists and people in
229 * If a regression made it into a proper mainline release during the past
230 twelve months, ensure to tag the fix with "Cc: stable@vger.kernel.org", as a
231 "Fixes:" tag alone does not guarantee a backport. Please add the same tag,
239 * Whenever you want to swiftly resolve a regression that recently also made it
240 into a proper mainline, stable, or longterm release, fix it quickly in
246 backporting by dropping the stable team a note once the fix was mainlined;
248 the fix otherwise might land at the end of a huge patch queue.
254 Linus, ideally with them being in linux-next at least briefly. Hence, if a
258 periods mentioned above by reviewing regression fixes in a timely manner.
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
291 Check out Documentation/admin-guide/reporting-regressions.rst, it covers a lot
298 * who's in charge for finding the root cause of a regression
300 * how to handle tricky situations, e.g. when a regression is caused by a
301 security fix or when fixing a regression might cause another one
306 Send a mail to the regressions mailing list (regressions@lists.linux.dev) while
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
355 deciding to release a new version or extend the development phase. For this they
363 important unexpectedly comes up -- for example a bigger problem in the Linux
364 kernel or something in real life that's keeping us away from keyboards for a
366 immediately write a fix and commit it to a tree regularly merged to the affected
375 which regzbot normally sends out once a week on Sunday evening (UTC), which is a
403 By using a 'regzbot command' in a direct or indirect reply to the mail with the
408 regzbot consider your mail as a regressions report added to the tracking, as
410 such command, which makes regzbot consider the parent mail as a report for a
416 or itself is a reply to that mail:
422 * Monitor a discussion or bugzilla.kernel.org ticket where additions aspects of
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
433 or a ticket in a bug tracker that are slightly related, but about a different
438 * Mark a regression as fixed by a commit that is heading upstream or already
443 * Mark a regression as a duplicate of another one already tracked by regzbot::
447 * Mark a regression as invalid::
449 #regzbot invalid: wasn't a regression, problem has always existed
457 contains a `getting started guide <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_star…
464 Find below a few real life examples of how Linus Torvalds expects regressions to
470 If you break existing user space setups THAT IS A REGRESSION.
505 more. Maybe there's a serious security issue with how we did things,
507 there was some fundamental other breakage that just _had_ to have a
513 feature any more. There's a number of fields in /proc/<pid>/stat that
515 the kernel any more, or because showing them was a mistake (typically
524 your user space then". It was a kernel change that exposed the
526 have a "upgrade in place" model. We don't have a "upgrade with new
539 undocumented behavior, it sucks to be you" or "there's a better way to
567 simply because of a kernel bug" is at all relevant.
576 doesn't make for too much trouble for users (ie "ok, there are a
577 handful of users, and they can use a kernel command line to work
578 around it" kind of things) we've also been a bit less strict.
583 that means that it's basically regular kernel code with a flag saying
605 So clearly behavior changes all the time and we don't consider that a
608 The rule for a regression for the kernel is that some real user
609 workflow breaks. Not some test. Not a "look, I used to be able to do
627 > Kernel had a bug which has been fixed
635 Bugs happen. That's a fact of life. Arguing that "we had to break
636 something because we were fixing a bug" is completely insane. We fix
637 tens of bugs every single day, thinking that "fixing a bug" means that
656 Breaking a user workflow for a "bug" is absolutely the WORST reason
663 And without users, your program is not a program, it's a pointless
667 don't break users". Because "I fixed a bug" is absolutely NOT AN
668 ARGUMENT if that bug fix broke a user setup. You actually introduced a
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
682 without upgrading some other random binary, then we have a problem.
690 a success case of security. It's a failure case.
701 /proc/self/mountinfo), then it's a regression.
726 We have programs that use that ABI and thus it's a regression if they break.
730 > Now this got me wondering if Debian _unstable_ actually qualifies as a
743 What's instructive about it is that I reverted a commit that wasn't
746 improved IO patterns it caused then ended up revealing a user-visible
747 regression due to a real bug in a completely unrelated area.
751 example of what counts as a regression, and what the whole "no
754 another problem, and as such caused a kernel upgrade to fail for a
758 not based on some "it changes the ABI" or "it caused a bug" concept.
765 patterns once we've decided just how to handle the fact that we had a
772 re-introduced (perhaps even backported as a stable patch) once we have
776 kernel-userspace ABI, or fix a bug, or about whether the old code
782 worth just bringing it up every once in a while
796 files which use a more restrictive license.