| |||||||||||||
Kernel bugs: out of control?Kernel bugs: out of control?Posted May 11, 2006 19:16 UTC (Thu) by oak (subscriber, #2786)In reply to: Kernel bugs: out of control? by malor Parent article: Kernel bugs: out of control?
> The problem with the backporting is that it's boring work, and
(Log in to post comments)
Kernel bugs: out of control? Posted May 11, 2006 23:52 UTC (Thu) by malor (subscriber, #2973) [Link] Yes, I think exactly that. Development speed is not the same as code quality. The new process is tuned to let them do more of the 'fun' stuff (writing new code), and force them to do less of the 'unfun' stuff, like making sure things actually work. It's also to force more testers; they've explicitly said one of the reasons they're doing it this way is to force people to test new code.
I don't mind testing code when there's a call for testers (and if I can slot in some time). I do mind being forced to test beta-quality code by them calling it 'stable' and refusing to support code that's more than two months old.
As far as exponentiation goes, you're exactly right... I'm not sure if I hit this idea yet in this thread. What that means is that as the kernel grows, development needs to slow down, to cover all the various interactions. Instead, they're _speeding up_, not testing, and expecting the Rest of World to fix their problems.
I tried to report the APIC bug on that VIA board. I first emailed the ACPI author (got my acronyms confused :) ), who very promptly replied, and politely told me I was talking to the wrong person. Then I tried mailing the APIC maintainers twice, but didn't get a reply. I dropped it after that... probably should have sent it to the catchall address, but forgot it. And now I don't have the board anymore, so a bug report won't be very useful.
The 865 bugs I can't diagnose, because it's all remote, so I haven't even tried to report it. Those machines are production, and I can't afford to take them down for testing. So my bug report wouldn't be very useful. And 2.6.16 has worked well so far, although the unending reboots are painful.
And 2.6.0 through 2.6.8 or so worked great on that same board.... so I really shouldn't have HAD to file bug reports. I was, after all, tracking a 'stable' kernel. Stuff that worked in 2.6.0 should work in 2.6.16.
Kernel bugs: out of control? Posted May 12, 2006 0:02 UTC (Fri) by malor (subscriber, #2973) [Link] Oops, I inserted a paragraph in the wrong place. If you swap the last two paragraphs, it'll be more readable, although the concluding note will be in the wrong place. :)
Kernel bugs: out of control? Posted May 16, 2006 17:49 UTC (Tue) by oak (subscriber, #2786) [Link] > And 2.6.0 through 2.6.8 or so worked great on that same board....> so I really shouldn't have HAD to file bug reports. I was, after all, > tracking a 'stable' kernel. Stuff that worked in 2.6.0 should work > in 2.6.16. You cannot really expect that unless you know that there's a regularly executed test setup: - with the same HW as yours - with the similar software and same kind of load as yours For example fixing a bug (for a setup developer has) might make (e.g. an already existing) bug somewhere else in the code happen more likely in your setup. Only testing and error detection inside & outside kernel can help in catching those. The testing has to be automated, it should not produce (too many) false positives, and it has to pinpoint fairly well where the problem happens so that the bugs can be fixed. Otherwise only alternative developer has is to resolve the bugs as WORKSFORME. It would be nice if kernel developers would provide an automated test-set for people who "live on the bleeding edge" which they could run on their test setups before deploying the kernel on production machine. If the test-set outputs an error, you could just forward it to kernel.org and the automatically produced bug report would have all the relevant info; your kernel config, HW info, OOPS etc... If the automated test-set would go through, then you could do your own tests on the kernel before putting it into real use. And if those fail, you could propose tests to be added to the automated test-set so that those kind of problems are caught earlier.
|
|||||||||||||