On Wed, 16 Apr 2008, David Newall wrote:timely frequently means the code was merged in -rc1/2 and was fixed before the final release of the same version. given the huge variety of hardware and workloads, it's just too easy for there to be cases where any trade-off you make (code size, performance, memory usage, common case definitions) can turn around and bite you. In addition frequently hardware doesn't work quite the way the design specs say that it should (completely ignoring the fact that many drivers are reverse engineered). what's most important is that when a case shows up it gets addressed promptly I'd rather have a developer/maintainer who introduces and fixed 100 bug, but fixes them promptly, as opposed to one who only introduces one bug, but refuses to consider fixing the code 'because they don't make mistakes like that' (usadly a common attitude from people who produce very good code much of the time) best of all is a developer/maintainer who writes very good code and is willing to accept the fact that they make mistakes and fixes the code promptly, but those people are extremely rare, and usually they emerge from the pool of people who make more mistakes and fix them promptly, which is an added reason I'm more tolerant of that group. David Lang --
| Andrew Morton | -mm merge plans for 2.6.23 |
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Gabriel C | Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS] |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| David Miller | [GIT]: Networking |
| Thomas Jarosch | Re: TCP connection stalls under 2.6.24.7 |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
