Kernel regression tracking, part 1
Kernel regression tracking, part 1
Posted Nov 1, 2017 12:27 UTC (Wed) by Paf (subscriber, #91811)In reply to: Kernel regression tracking, part 1 by neilbrown
Parent article: Kernel regression tracking, part 1
Another thought:
Regressions can sort of... sneak in. They are often unintended side-effects of changes, and can gradually accumulate because no one is looking at an area (notably of performance) any more. And then, gradually, something that used to be all tuned up doesn’t work well any more.
Regressions can sort of... sneak in. They are often unintended side-effects of changes, and can gradually accumulate because no one is looking at an area (notably of performance) any more. And then, gradually, something that used to be all tuned up doesn’t work well any more.
That’s a slightly different argument, though. I, like you, don’t really understand tracking regressions vs new bugs. So little of the kernel is actually providing totally novel functionality, outside of drivers, that I think most bugs could be considered regressions in a certain light. I mean, when you do the next rewrite of path lookup, that’s great and useful work, but it doesn’t provide new end user functionality, just performance. So I guess any bugs in it are regressions...?