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::
68 * When you receive a report by mail that did not CC the list, immediately bring
69 it into the loop by sending at least a brief "Reply-all" with the list CCed;
70 try to ensure it gets CCed again in case you reply to a reply that omitted
73 * If a report submitted in a bug tracker hits your Inbox, forward or bounce it
81 * For mailed reports, check if the reporter included a "regzbot command" like
82 ``#regzbot introduced 1f2e3d4c5b6a``. If not, send a reply (with the
83 regressions list in CC) with a paragraph like the following:::
88 you can specify a range using commit-ids as well or state a single commit-id
97 * When forwarding a regressions reported to a bug tracker, include a paragraph
118 Link: https://bugzilla.kernel.org/show_bug.cgi?id=1234567890
120 * Add a "Fixes:" tag to specify the commit causing the regression.
135 As a Linux kernel developer, you are expected to give your best to prevent
136 situations where a regression caused by a recent change of yours leaves users
139 * Run a kernel with a regression that impacts usage.
145 should be less than two. And it ought to be just a few days, if the issue is
150 rules of thumb as a guide.
155 latter concerns a severe issue (e.g. acute security vulnerability, data loss,
158 * Expedite fixing mainline regressions that recently made it into a proper
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
171 bothering many users -- either in general or in prevalent conditions like a
174 * Aim to mainline a fix by Sunday after the next, if the culprit made it
175 into a recent mainline, stable, or longterm release (either directly or via
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
186 culprit was mainlined more than a year ago.
191 dangerous way to fix a regression. Don't worry about mainlining a fixed
200 * Consider CCing Linus on discussions or patch review, if a regression seems
203 know such a regression made it into a mainline, stable, or longterm release.
210 * In case you are unsure if a fix is worth the risk applying just days before
211 a new mainline release, send Linus a mail with the usual lists and people in
222 * If a regression made it into a proper mainline release during the past
223 twelve months, ensure to tag the fix with "Cc: stable@vger.kernel.org", as a
224 "Fixes:" tag alone does not guarantee a backport. Please add the same tag,
232 * Whenever you want to swiftly resolve a regression that recently also made it
233 into a proper mainline, stable, or longterm release, fix it quickly in
239 backporting by dropping the stable team a note once the fix was mainlined;
241 the fix otherwise might land at the end of a huge patch queue.
247 Linus, ideally with them being in linux-next at least briefly. Hence, if a
251 periods mentioned above by reviewing regression fixes in a timely manner.
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
284 Check out Documentation/admin-guide/reporting-regressions.rst, it covers a lot
291 * who's in charge for finding the root cause of a regression
293 * how to handle tricky situations, e.g. when a regression is caused by a
294 security fix or when fixing a regression might cause another one
299 Send a mail to the regressions mailing list (regressions@lists.linux.dev) while
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
349 deciding to release a new version or extend the development phase. For this they
357 important unexpectedly comes up -- for example a bigger problem in the Linux
358 kernel or something in real life that's keeping us away from keyboards for a
360 immediately write a fix and commit it to a tree regularly merged to the affected
369 which regzbot normally sends out once a week on Sunday evening (UTC), which is a
397 By using a 'regzbot command' in a direct or indirect reply to the mail with the
402 regzbot consider your mail as a regressions report added to the tracking, as
404 such command, which makes regzbot consider the parent mail as a report for a
410 or itself is a reply to that mail:
416 * Monitor a discussion or bugzilla.kernel.org ticket where additions aspects of
417 the issue or a fix are discussed -- for example the posting of a patch fixing
426 * Point to a place with further details of interest, like a mailing list post
427 or a ticket in a bug tracker that are slightly related, but about a different
432 * Mark a regression as fixed by a commit that is heading upstream or already
437 * Mark a regression as a duplicate of another one already tracked by regzbot::
441 * Mark a regression as invalid::
443 #regzbot invalid: wasn't a regression, problem has always existed
451 contains a `getting started guide <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_star…
458 Find below a few real life examples of how Linus Torvalds expects regressions to
464 If you break existing user space setups THAT IS A REGRESSION.
499 more. Maybe there's a serious security issue with how we did things,
501 there was some fundamental other breakage that just _had_ to have a
507 feature any more. There's a number of fields in /proc/<pid>/stat that
509 the kernel any more, or because showing them was a mistake (typically
518 your user space then". It was a kernel change that exposed the
520 have a "upgrade in place" model. We don't have a "upgrade with new
533 undocumented behavior, it sucks to be you" or "there's a better way to
561 simply because of a kernel bug" is at all relevant.
570 doesn't make for too much trouble for users (ie "ok, there are a
571 handful of users, and they can use a kernel command line to work
572 around it" kind of things) we've also been a bit less strict.
577 that means that it's basically regular kernel code with a flag saying
599 So clearly behavior changes all the time and we don't consider that a
602 The rule for a regression for the kernel is that some real user
603 workflow breaks. Not some test. Not a "look, I used to be able to do
621 > Kernel had a bug which has been fixed
629 Bugs happen. That's a fact of life. Arguing that "we had to break
630 something because we were fixing a bug" is completely insane. We fix
631 tens of bugs every single day, thinking that "fixing a bug" means that
650 Breaking a user workflow for a "bug" is absolutely the WORST reason
657 And without users, your program is not a program, it's a pointless
661 don't break users". Because "I fixed a bug" is absolutely NOT AN
662 ARGUMENT if that bug fix broke a user setup. You actually introduced a
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
676 without upgrading some other random binary, then we have a problem.
684 a success case of security. It's a failure case.
695 /proc/self/mountinfo), then it's a regression.
720 We have programs that use that ABI and thus it's a regression if they break.
724 > Now this got me wondering if Debian _unstable_ actually qualifies as a
737 What's instructive about it is that I reverted a commit that wasn't
740 improved IO patterns it caused then ended up revealing a user-visible
741 regression due to a real bug in a completely unrelated area.
745 example of what counts as a regression, and what the whole "no
748 another problem, and as such caused a kernel upgrade to fail for a
752 not based on some "it changes the ABI" or "it caused a bug" concept.
759 patterns once we've decided just how to handle the fact that we had a
766 re-introduced (perhaps even backported as a stable patch) once we have
770 kernel-userspace ABI, or fix a bug, or about whether the old code
776 worth just bringing it up every once in a while
790 files which use a more restrictive license.