lkml.org 
[lkml]   [1997]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 2.0.31 : please!
>>    That is a fair comment.  However I believe that we could do with some
>> serious effort to ensure that things don't get broken in the course of
>> adding new features. I don't think that a 2.1.x release should be held up
>> because of this, however if a serious testing effort was applied to the
>> pre-patches it would provide a list of things that need work. Then
>> hopefully most of these issues would be fixed before the full releae of the
>> 2.1.x version.

>> I believe that I have proved that it is impossible to test all
>> combinations of kernel options. But I believe that if we test a reasonable
>> number of kernels then we can discover (and therefore fix) bugs that might
>> otherwise hang around for ages. One reason for doing this in the
>> development kernels is that it's easier to keep track of what you're doing
>> if you do it all at once. Some people such as Alan Cox and Dave Miller
>> work on many different parts of the kernel. If they were politely informed
>> that a new feature they had added had broken something else shortly after
>> the release of the code then I'm sure that they would be able to either fix
>> the problem or give some background information that allows a less skilled
>> programmer to fix it with a minimum amount of effort. However if the bug
>> goes undiscovered for 6 months because no-one tries compiling a certain
>> combination of modules (or whatever the trigger is) then they are likely to
>> require much more work to fix it.

>By defining even more levels of "official" release policy, you are running
>the danger of blocking the creativity of the biggest contributers to
>Linux. In my mind, the model works like this:

I had no intention of implying that we should delay releases of kernels
for any reason. As I stated in the second paragraph that you quoted the
aim should be to discover bugs ASAP to enable them to be fixed more quickly
and easily.


Russell Coker

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.209 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site