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
68 * When you receive a report by mail that did not CC the list, immediately bring
70 try to ensure it gets CCed again in case you reply to a reply that omitted
93 you want to see tracked; that's important, as regzbot will later look out
104 Regzbot will then automatically associate patches with the report that
126 these tags are of great value for everyone (you included) that might be looking
142 a kernel with a regression that seriously impacts usage", "continue running an
145 supported kernel series that lack required features".
170 more urgency than regressions in mainline pre-releases. That changes after
269 true for the Linux kernel as well. That's why Thorsten Leemhuis volunteered to
272 that's why regression tracking is done on a best effort basis.
292 introduced`` command outlined above; if they don't do that, someone else can
293 take care of that using ``#regzbot ^introduced``.
296 sure to do something that was expected long before regzbot came to light: add
306 need to be aware of all unfixed regression; to do that, Linus is known to look
314 kernel or something in real life that's keeping us away from keyboards for a
365 of the `introduced` commands or in replies to the mail that used one of them
366 or itself is a reply to that mail:
379 will consider all messages in that thread or ticket as related to the fixing
383 or a ticket in a bug tracker that are slightly related, but about a different
388 * Mark a regression as fixed by a commit that is heading upstream or already
420 If you break existing user space setups THAT IS A REGRESSION.
432 and the corollary is that when regressions *do* occur, we admit to
435 The fact that you have apparently been denying the regression now for
436 three weeks means that I will revert, and I will stop pulling apparmor
447 update that other program" kind of limitations. If the kernel used to
448 work for you, the rule is that it continues to work for you.
452 that were basically entirely unavoidable, and people _tried_hard_ to
456 and people actually depended on that fundamentally broken model. Maybe
457 there was some fundamental other breakage that just _had_ to have a
460 And notice that this is very much about *breaking* peoples environments.
463 feature any more. There's a number of fields in /proc/<pid>/stat that
466 an information leak). But the numbers got replaced by zeroes, so that
467 the code that used to parse the fields still works. The user might not
474 your user space then". It was a kernel change that exposed the
475 problem, it needs to be the kernel that corrects for it, because we
484 And yes, I realize that the kernel is "special" in this respect. I'm
487 I have seen, and can point to, lots of projects that go "We need to
488 break that use case in order to make progress" or "you relied on
490 do what you want to do, and you have to change to that new better
491 way", and I simply don't think that's acceptable outside of very early
492 alpha releases that have experimental users that know what they signed
493 up for. The kernel hasn't been in that situation for the last two
498 about internal kernel API's, and the people who do that then also
499 obviously have to fix up all the in-kernel users of that API. Nobody
513 Users are literally the _only_ thing that matters.
515 No amount of "you shouldn't have used this" or "that behavior was
516 undefined, it's your own fault your app broke" or "that used to work
520 like "serious security issue" etc that just forces us to make changes
521 that may break user space. But even then the rule is that we don't
522 really have other options that would allow things to continue.
524 And obviously, if users take years to even notice that something
525 broke, or if we have sane ways to work around the breakage that
530 But no, "that was documented to be broken" (whether it's because the
532 irrelevant. If staging code is so useful that people end up using it,
533 that means that it's basically regular kernel code with a flag saying
536 The other side of the coin is that people who talk about "API
543 It's entirely about "we caused problems for user space that used to work".
549 That would mean that we could never make any changes at all.
555 So clearly behavior changes all the time and we don't consider that a
558 The rule for a regression for the kernel is that some real user
574 The whole point of "we do not regress" is so that people can upgrade
579 That is *ENTIRELY* immaterial.
585 Bugs happen. That's a fact of life. Arguing that "we had to break
587 tens of bugs every single day, thinking that "fixing a bug" means that
594 Because the only thing that matters IS THE USER.
596 How hard is that to understand?
609 It's basically saying "I took something that worked, and I broke it,
610 but now it's better". Do you not see how f*cking insane that statement
614 piece of code that you might as well throw away.
618 ARGUMENT if that bug fix broke a user setup. You actually introduced a
619 MUCH BIGGER bug by "fixing" something that the user clearly didn't
627 upgrade random other tools that I don't even care about as I develop
639 Honestly, security people need to understand that "not working" is not
642 Yes, "not working" may be secure. But security in that case is *pointless*.
654 similar that makes us go "Oh Gods, we really have to break things".
660 If you made an interface that can be used without parsing the
665 issues that way. There aren't that many of them.
676 We have programs that use that ABI and thus it's a regression if they break.
683 Oh, if the kernel breaks some standard user space, that counts. Tons
693 What's instructive about it is that I reverted a commit that wasn't
695 and did it very well. In fact it did it _so_ well that the much
699 The actual details of that regression are not the reason I point that
700 revert out as instructive, though. It's more that it's an instructive
707 The point here being that we revert based on user-reported _behavior_,
712 previously benign behavior of that old issue.
714 And never fear, we'll re-introduce the fix that improved on the IO
715 patterns once we've decided just how to handle the fact that we had a
716 bad interaction with an interface that people had then just happened
717 to rely on incidental behavior for before. It's just that we'll have
718 to hash through how to do that (there are no less than three different
720 be more coming...). In the meantime, I reverted the thing that exposed
730 Anyway, that was my little aside on the whole regression thing. Since
731 it's that "first rule of kernel programming", I felt it is perhaps
744 is available under CC-BY-4.0, as versions of this text that were processed