Lines Matching full:it
8 Linux kernel development" means in practice for developers. It complements
10 user's point of view; if you never read that text, go and at least skim over it
20 * When receiving a mailed report that did not CC the list, bring it into the
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
94 Note the caret (^) before the "introduced": it tells regzbot to treat the
132 All this is expected from you and important when it comes to regression, as
151 than three weeks after the regression's culprit was identified. Ideally it
152 should be less than two. And it ought to be just a few days, if the issue is
165 * Expedite fixing mainline regressions that recently made it into a proper
181 * Aim to mainline a fix by Sunday after the next, if the culprit made it
191 * It's strongly discouraged to delay mainlining regression fixes till the next
197 * Always consider reverting the culprit, as it's often the quickest and least
210 know such a regression made it into a mainline, stable, or longterm release.
219 CC; in it, summarize the situation while asking him to consider picking up
229 * If a regression made it into a proper mainline release during the past
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
253 to account for the time it takes to get fixes tested, reviewed, and merged by
255 fix is urgent, make it obvious to ensure others handle it appropriately.
291 Check out Documentation/admin-guide/reporting-regressions.rst, it covers a lot
303 Whom to ask for advice when it comes to regressions
325 Earlier attempts to manually track regressions have shown it's an exhausting and
335 it's looking out for posted or committed patches referencing such reports
353 It's in the interest of everyone if you do, as kernel maintainers like Linus
365 while. Hence, it's best to tell regzbot about every regression, except when you
366 immediately write a fix and commit it to a tree regularly merged to the affected
388 regular issues. But it's okay for the Linux kernel's regression tracker if you
411 regression which it starts to track.
472 It's not ok to say "but we'll fix the user space setup".
494 and simply not have to worry about it.
498 work for you, the rule is that it continues to work for you.
504 after it is decades old and nobody uses it with modern kernels any
523 reverted. And it gets fixed in the *kernel*. Not by saying "well, fix
524 your user space then". It was a kernel change that exposed the
525 problem, it needs to be the kernel that corrects for it, because we
535 proud of it.
539 undocumented behavior, it sucks to be you" or "there's a better way to
547 internal problems by saying "you now need to do XYZ", but then it's
550 can say "I now broke the API you used, and now _you_ need to fix it
551 up". Whoever broke something gets to fix it too.
566 undefined, it's your own fault your app broke" or "that used to work
578 around it" kind of things) we've also been a bit less strict.
580 But no, "that was documented to be broken" (whether it's because the
582 irrelevant. If staging code is so useful that people end up using it,
583 that means that it's basically regular kernel code with a flag saying
593 It's entirely about "we caused problems for user space that used to work".
625 the kernel and never have to worry about it.
641 they get found, they get fixed, and it has nothing to do with "we
648 Anybody who uses "but it was buggy" as an argument is entirely missing
649 the point. As far as the USER was concerned, it wasn't buggy - it
652 Maybe it worked *because* the user had taken the bug into account,
653 maybe it worked because the user didn't notice - again, it doesn't
654 matter. It worked for the user.
659 It's basically saying "I took something that worked, and I broke it,
660 but now it's better". Do you not see how f*cking insane that statement
663 And without users, your program is not a program, it's a pointless
673 other programs at all. It is absolutely required, because flag-days
676 And it is also required simply because I as a kernel developer do not
690 a success case of security. It's a failure case.
700 parse it wrongly - see the fairly recent example of adding uuid's to
701 /proc/self/mountinfo), then it's a regression.
720 it's clearly NOT an internal tracepoint. By definition. It's being
726 We have programs that use that ABI and thus it's a regression if they break.
741 it's very annoying, it's perhaps also instructive.
743 What's instructive about it is that I reverted a commit that wasn't
744 actually buggy. In fact, it was doing exactly what it set out to do,
745 and did it very well. In fact it did it _so_ well that the much
746 improved IO patterns it caused then ended up revealing a user-visible
750 revert out as instructive, though. It's more that it's an instructive
753 API's, and it didn't introduce any new bugs. But it ended up exposing
755 user. So it got reverted.
758 not based on some "it changes the ABI" or "it caused a bug" concept.
759 The problem was really pre-existing, and it just didn't happen to
767 to rely on incidental behavior for before. It's just that we'll have
771 the problem to users for this release, even if I hope it will be
773 consensus about the issue it exposed.
775 Take-away from the whole thing: it's not about whether you change the
777 "should never have worked in the first place". It's about whether
781 it's that "first rule of kernel programming", I felt it is perhaps
782 worth just bringing it up every once in a while