lkml.org 
[lkml]   [2005]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: RFD: Kernel release numbering
    Date
    Clearly I picked a bad week to go on vacation..


    On Fri, 04 Mar 2005
    10:18:41 -0800, Linus Torvalds wrote:
    [...]
    >
    > Alan, I think your problem is that you really think that the tree _I_ want
    > is what _you_ want.
    >
    > I look at this from a _layering_ standpoint. Not from a "stable tree"
    > standpoint at all.
    >
    > We're always had the "wild" kernels, and 90% of the time the point of the
    > "wild" kernels has been to let people test out the experimental stuff,
    > that's not always ready for merging. Like it or not, I've considered even
    > the -ac kernel historically very much a "wild" thing, not a "bugfixes"
    > thing.
    >
    > What I'd like to set up is the reverse. The same way the "wild" kernels
    > tend to layer on top of my standard kernel, I'd like to have a lower
    > level, the "anti-wild" kernel. Something that is comprised of patches
    > that _everybody_ can agree on, and that doesn't get anything else. AT ALL.
    >

    That is what I'm trying to do w/ my tree; obvious fixes only. Most of
    the patches I've included in 2.6.10-asX have been stupid build fixes, and
    basic C problems (ie, deref'ing a pointer before it's been assigned). The
    main time I make exceptions for that is for security fixes.


    > And that means that such a kernel would not get all patches that you'd
    > want. That's fine. That was never the aim of it. The _only_ point of
    > this kernel would be to have a baseline that nobody can disagree with.
    >
    > In other words, it's not a "let's fix all serious bugs we can fix", but
    > a "this is the least common denominator that is basically acceptable to
    > everybody, regardless of what their objectives are".
    >
    > So if you want to fix a security issue, and the fix is too big or
    > invasive or ugly for the "least common denominator" thing, then it
    > simply does not _go_ into that kernel. At that point, it goes into an
    > -ac kernel, or into my kernel, or into a vendor kernel. See?
    >

    This is understandable. I have included security fixes in -as that were
    non-trivial; if a 2.6.x.y tree is not willing to include them, then I
    guess it won't be what I was hoping. I had emailed Chris before going on
    vacation, offering to work with him on 2.6.x.y (which would allow me to
    drop -as), but if security fixes aren't a higher priority thing (even
    in the face of invasive/ugly changes), then I guess there's still a need
    for -as/-ac.



    -
    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.027 / U:0.768 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site