lkml.org 
[lkml]   [2005]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Why is 2.6.12.2 less stable on my laptop than 2.6.10?
On Fri, 15 Jul 2005, Mark Gross wrote:

> On Thursday 14 July 2005 19:09, Dave Jones wrote:
>> On Fri, Jul 15, 2005 at 03:45:28AM +0200, Jesper Juhl wrote:
>> >>> The problem is the process, not than the code.
>> >>> * The issues are too much ad-hock code flux without enough
>> >>> disciplined/formal regression testing and review.
>> >>
>> >> It's basically impossible to regression test swsusp except to release
>> >> it. Its success or failure depends on exactly the driver
>> >> combination/platform/BIOS version etc. e.g. all drivers have to
>> >> cooperate and the particular bugs in your BIOS need to be worked
>> >> around etc. Since that is quite fragile regressions are common.
>> >>
>> >> However in some other cases I agree some more regression testing
>> >> before release would be nice. But that's not how Linux works. Linux
>> >> does regression testing after release.
>> >
>> > And who says that couldn't change?
>> >
>> > In my oppinion it would be nice if Linus/Andrew had some basic
>> > regression tests they could run on kernels before releasing them.
>>
>> The problem is that this wouldn't cover the more painful problems
>> such as hardware specific problems.
>>
>> As Fedora kernel maintainer, I frequently get asked why peoples
>> sound cards stopped working when they did an update, or why
>> their system no longer boots, usually followed by a
>> "wasnt this update tested before it was released?"
>>
>> The bulk of all the regressions I see reported every time
>> I put out a kernel update rpm that rebases to a newer
>> upstream release are in drivers. Those just aren't going
>> to be caught by folks that don't have the hardware.
>
> This problem is the developer making driver changes without have the resources
> to test the changes on a enough of the hardware effected by his change, and
> therefore probubly shouldn't be making changes they cannot realisticaly test.
>
> What would be wrong in expecting the folks making the driver changes have some
> story on how they are validating there changes don't break existing working
> hardware? I could probly be accomplished in open source with subsystem
> testing volenteers.

in that case you will have a lot of drivers that won't work becouse the
rest of the kernel has changed and they haven't been changed to match.

do you have the resources to test a few hundred network cards, video
cards, etc? if you do great, hope you can help out, if not why should you
require other kernel folks to have resources that you don't have?

David Lang

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-07-16 00:32    [W:0.067 / U:4.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site