Lines Matching full:that

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
47 only fixing part of the issue that caused the regression, you may use
71 * When you receive a report by mail that did not CC the list, immediately bring
73 try to ensure it gets CCed again in case you reply to a reply that omitted
96 you want to see tracked; that's important, as regzbot will later look out
107 Regzbot will then automatically associate patches with the report that
133 these tags are of great value for everyone (you included) that might be looking
146 * Run a kernel with a regression that impacts usage.
156 How to realize that in practice depends on various factors. Use the following
165 * Expedite fixing mainline regressions that recently made it into a proper
168 * Do not consider regressions from the current cycle as something that can wait
199 variant later: that should be straight-forward, as most of the code went
213 from the mailing list: he is totally fine with that for uncontroversial
236 mainline as well -- and if that seems likely, take hold of the report. If in
239 * Whenever you want to swiftly resolve a regression that recently also made it
242 above). That's because the stable team normally does neither revert nor fix
243 any changes that cause the same problems in mainline.
320 true for the Linux kernel as well. That's why Thorsten Leemhuis volunteered to
323 that's why regression tracking is done on a best effort basis.
343 introduced`` command outlined above; if they don't do that, someone else can
344 take care of that using ``#regzbot ^introduced``.
347 sure to do something that was expected long before regzbot came to light: add
356 need to be aware of all unfixed regression; to do that, Linus is known to look
364 kernel or something in real life that's keeping us away from keyboards for a
415 of the `introduced` commands or in replies to the mail that used one of them
416 or itself is a reply to that mail:
429 will consider all messages in that thread or ticket as related to the fixing
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
470 If you break existing user space setups THAT IS A REGRESSION.
482 and the corollary is that when regressions *do* occur, we admit to
485 The fact that you have apparently been denying the regression now for
486 three weeks means that I will revert, and I will stop pulling apparmor
497 update that other program" kind of limitations. If the kernel used to
498 work for you, the rule is that it continues to work for you.
502 that were basically entirely unavoidable, and people _tried_hard_ to
506 and people actually depended on that fundamentally broken model. Maybe
507 there was some fundamental other breakage that just _had_ to have a
510 And notice that this is very much about *breaking* peoples environments.
513 feature any more. There's a number of fields in /proc/<pid>/stat that
516 an information leak). But the numbers got replaced by zeroes, so that
517 the code that used to parse the fields still works. The user might not
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
534 And yes, I realize that the kernel is "special" in this respect. I'm
537 I have seen, and can point to, lots of projects that go "We need to
538 break that use case in order to make progress" or "you relied on
540 do what you want to do, and you have to change to that new better
541 way", and I simply don't think that's acceptable outside of very early
542 alpha releases that have experimental users that know what they signed
543 up for. The kernel hasn't been in that situation for the last two
548 about internal kernel API's, and the people who do that then also
549 obviously have to fix up all the in-kernel users of that API. Nobody
563 Users are literally the _only_ thing that matters.
565 No amount of "you shouldn't have used this" or "that behavior was
566 undefined, it's your own fault your app broke" or "that used to work
570 like "serious security issue" etc that just forces us to make changes
571 that may break user space. But even then the rule is that we don't
572 really have other options that would allow things to continue.
574 And obviously, if users take years to even notice that something
575 broke, or if we have sane ways to work around the breakage that
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
586 The other side of the coin is that people who talk about "API
593 It's entirely about "we caused problems for user space that used to work".
599 That would mean that we could never make any changes at all.
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
624 The whole point of "we do not regress" is so that people can upgrade
629 That is *ENTIRELY* immaterial.
635 Bugs happen. That's a fact of life. Arguing that "we had to break
637 tens of bugs every single day, thinking that "fixing a bug" means that
644 Because the only thing that matters IS THE USER.
646 How hard is that to understand?
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
664 piece of code that you might as well throw away.
668 ARGUMENT if that bug fix broke a user setup. You actually introduced a
669 MUCH BIGGER bug by "fixing" something that the user clearly didn't
677 upgrade random other tools that I don't even care about as I develop
689 Honestly, security people need to understand that "not working" is not
692 Yes, "not working" may be secure. But security in that case is *pointless*.
704 similar that makes us go "Oh Gods, we really have to break things".
710 If you made an interface that can be used without parsing the
715 issues that way. There aren't that many of them.
726 We have programs that use that ABI and thus it's a regression if they break.
733 Oh, if the kernel breaks some standard user space, that counts. Tons
743 What's instructive about it is that I reverted a commit that wasn't
745 and did it very well. In fact it did it _so_ well that the much
749 The actual details of that regression are not the reason I point that
750 revert out as instructive, though. It's more that it's an instructive
757 The point here being that we revert based on user-reported _behavior_,
762 previously benign behavior of that old issue.
764 And never fear, we'll re-introduce the fix that improved on the IO
765 patterns once we've decided just how to handle the fact that we had a
766 bad interaction with an interface that people had then just happened
767 to rely on incidental behavior for before. It's just that we'll have
768 to hash through how to do that (there are no less than three different
770 be more coming...). In the meantime, I reverted the thing that exposed
780 Anyway, that was my little aside on the whole regression thing. Since
781 it's that "first rule of kernel programming", I felt it is perhaps
794 is available under CC-BY-4.0, as versions of this text that were processed