[lkml]   [1997]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.046 / U:51.348 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site