lkml.org 
[lkml]   [2005]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RFD: Kernel release numbering


    On Fri, 4 Mar 2005, Linus Torvalds wrote:
    >
    > In other words: I'm talking about scalability of development, not about
    > fixing every single serious bug. I think this one will catch the
    > embarrassing brown-paper-bag kinds of things, and maybe 90% of the "duh,
    > we had this race forever, but we never even realized", but it wouldn't
    > solve the ones where we had "damn, we did the locking wrong".

    Btw, I also think that this means that the sucker-tree should never aim to
    be a "2.6.x.y" kind of release tree. If we do a "2.6.x.y" release, the
    sucker tree would be _included_ in that release (and it may indeed be all
    of it - most of the time it probably would be), but we should not assume
    that "2.6.x.y" _has_ to be just the sucker tree.

    We might want to release a "2.6.x.y" that contains a patch that is too big
    or too intrusive (or otherwise controversial) to really be valid in the
    sucker-tree.

    And I'd want that to be very much explicit in the "charter" for the
    sucker-tree. Exactly because the whole point (to me, at least) is to make
    it _easy_ to maintain. There should never be any discussion at all about
    patches: either they are universally loved, or they are not. And if the
    sucker-tree is seen as a 2.6.x.y release tree, then that will _inevitably_
    mean that people will start discussing whether one patch or the other is
    supposed to go in.

    My personal gut feeling is that 90% of the patches I _ever_ see are
    "obvious". If we also cut them down to "must fix an oops/hang/roothole", I
    think we'll actually get quite far with a sucker tree. We'll never get all
    the way, but exactly because the tree wouldn't _try_ to get all the way,
    it would be a lot easier to maintain.

    And let's face it, just getting 50% of the way and having somethign that
    catches the brown-paper-bag stuff so that nobody else every needs to worry
    about them is really worthwhile.

    Linus
    -
    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: 2009-11-18 23:46    [W:0.038 / U:60.808 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site