On Sun, 9 Dec 2007, Alan Cox wrote:Btw, Alan, that "math" is total and utter BULLSH*T, and you should know that. "The one off regression" is likely the tip of an iceberg. If something regresses for one person, for that one person who tested and noticed and made a bug-report, there's probably a thousand people who haven't even tested the development kernel, or who had problems and just went back to the previous version. In contrast, reverting something will be guaranteed to not have those kinds of issues, since the only people who could notice are people for who it never worked in the first place. There's no "silent mass of people" that can be affected. This is why regressions are so important. They don't trump _everything_, but basically ignoring and letting them slide is *much* more painful than just reverting it. The biggest reason to ignore a regression is if nobody can even figure out where it came from, or reverting simply isn't an option for some really deep and fundamental issue. That doesn't seem to be the case here. So we should revert unless there is some known acceptable real fix. Linus --
| KOSAKI Motohiro | [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
| Nick Piggin | [patch 3/6] mm: fix fault vs invalidate race for linear mappings |
| Stefan Richter | Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures |
| Ingo Molnar | [bug] stuck localhost TCP connections, v2.6.26-rc3+ |
git: | |
| Peter Zijlstra | Re: [PATCH 3/3] Convert the UDP hash lock to RCU |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | Re: 2.6.25-rc8: FTP transfer errors |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Doug Evans | Re: Stabilizing Linux |
| Robert Blum | And another version of the INFO sheet |
| Marc CORSINI | find-1.2 (binaries only) |
| Yanek Martinson | Re: Porting g++ 1.40.3 |
