lkml.org 
[lkml]   [2005]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RFD: Kernel release numbering
    On Wed, Mar 02, 2005 at 07:10:47PM -0800, Randy.Dunlap wrote:

    > >For it to truly be a stable kernel, the only patches I'd expect to
    > >drivers would be ones fixing blindingly obvious bugs. No cleanups.
    > >No new functionality. I'd even question new hardware support if it
    > >wasn't just a PCI ID addition.
    >
    > Maybe I don't understand? Is someone expecting distro
    > quality/stability from kernel.org kernels?

    My complaint is the charade of calling it 'stable' when it clearly
    wouldn't be anything of the sort, given that a majority of the bugs our
    users experienced on rebasing were driver related.
    The core itself may be rock-solid, but if we're continually pulling
    in random driver updates of questionable quality with limited
    testing, the result as a whole isn't stable.

    > I don't, but maybe I'm one of those minorities.

    Putting the onus on distributions to make things stable is no
    excuse for the ever-increasing number of regressions each release.

    This might sound over-dramatic, but it's the current state as far
    as I'm concerned. The 2.6.8->2.6.9 update for Fedora users brought
    a bunch of carnage that took time to shake out. 2.6.9->2.6.10 I'm
    still picking up the pieces of. If the 2.6.10->2.6.11 update that
    I'll do for Fedora in a week or two turns out to have less regressions
    than the previous releases, I'll be stunned. Really.

    Already I'm wondering how many userspace packages are going to randomly
    stop working as they have done in previous releases. With the
    clear delineation of stable/development, we were able to say things
    like "we won't change a user visible interface in a stable series"
    Now, we don't have that. So we find things ranging from slabtop to
    alsa-lib completely break unless you update the userspace too.

    regressions like this is what I'm bitching about. There's nothing
    a vendor can do to make such things stable (other than dropping
    the various patches that introduce the breakage, but at ~4000 csets
    per release right now, there will be stuff that gets missed).
    Whilst the slabinfo example was a non-driver related regression,
    it's a good example of how little care we're taking these days
    to make sure existing userspace continues to work correctly.

    Some may suggest the close tracking of mainline is the problem.
    Maybe they're right. Maybe we should have stuck with a 2.6.5 kernel
    until Fedora Core 2 reached end of life, and gone with the old
    'have hundreds and hundreds of patches piling up' approach.

    But, as someone who has maintained vendor kernels that have tried
    both methods, the sticking close to mainline approach wins hands down.
    If something is broken, more often than not, I can bug the upstream
    developer and ask "hey, this is a wierd problem our fedora users hit,
    we don't have any patches against this code, can you take a look?"
    and developers have been very responsive, and helpful on many occasions,
    ultimatly leading bugs being fixed both in our kernel, and upstream.

    If I asked most upstream developers about a problem we've been facing
    with our 2.6.5 kernels, I'd get a much less helpful response.
    And rightly so. In their position I'd do exactly the same thing.

    Dave

    -
    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:4.306 / U:0.420 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site