lkml.org 
[lkml]   [2005]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: RFD: Kernel release numbering
    From
    Date
    On Thu, 2005-03-03 at 13:38 -0800, Stephen Hemminger wrote:
    > In all this discussion, I see a couple of underlying problems. The first
    > is what is the definition of stability. To many (mostly kernel developers)
    > the definition of stability "S" depends on number of bug reports "B":
    >
    > S(infinite) = B(0)
    > S(X) > S(Y) iff B(X) < B(Y)
    >
    > The problem is that the kernel community never sees many problems (filtered
    > through distro's), and the severity and importance of problem reports
    > is confused. Bug tracking could help, but it would have to be universal
    > and painless; bugzilla doesn't cut it.
    >
    > But many end-user's and IT types seem to feel that the definition
    > of stability is based on rate of change, ie patches (P) over time.
    >
    > S(X) > S(Y) iff P(X)/t > P(Y)/t
    >
    > These are the people who can't believe 2.6 is stable because they see so
    > much change. Having 2.6.x.y may make this group happy, but probably only
    > after such a long period that the the mainline kernel is 6 months ahead.
    >

    As I see it, there's those that would join in at different times. If the
    point was to get as many people moving to newer kernels, then this would
    make the most people comfortable to try a newer kernel. Maybe not the
    latest and greatest, but at least one that is closer to the newest one.

    Some might join 6 months behind, others 1 month and even those at 1
    week. I've talked to different people, and there are many at the 1 week
    point (the ones with the most critical systems would be at the 6 month,
    but the 1 weekers are the ones that would put it on a more non essential
    machine).

    > The whole point of the continuous 2.6 process,
    > was to avoid having the
    > multiple tree backporting mess that 2.5/2.4 had, especially the distro kernels
    > were all some hodge-podge of 2.5 and 2.4 stuff. Fixing the same bug on multiple
    > branches is a fundamentally flawed process that is sure to allow some bug fixes
    > to be missed.
    >

    Truth be told... don't worry about backporting fixes. This is the Open
    Source world, many eyes, and many developers. When a bug is reported,
    say to 2.6.x.y, then let some new kernel developer try to fix it, or
    whoever. Maybe even the one who reported the problem can fix it. But for
    that branch only. If this bug is in a earlier branch, then don't worry
    about it until someone else hits it, or say the one who fixed it, then
    goes back and checks other branches only if they want to.

    I'm saying, just have the branches available, with no guarantee that
    they have all the backported bugs, since no one is going to do it. But
    if someone wants it, then they can have a go at it. Maybe even a distro
    might add to it. This might just give people a central repository to
    all the fixes applied to a specific branch. Again, only bug fixes and
    nothing more.

    > The third group are those that install release 2.6.X and have some problem;
    > nobody wants to believe their problem is unique. So often, the user says makes
    > the fallacious argument that "if I had a problem, then all users will have the
    > problem, therefore it is unstable." These people will never be happy, they can
    > stay on 2.2.

    If there problem is truly a problem and if these people are capable of
    fixing it themselves or finding someone else to fix it. Then again, you
    have the fix at some point available for all.

    -- Steve


    -
    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-03-22 14:10    [W:0.024 / U:61.488 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site