lkml.org 
[lkml]   [2007]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 00/33] 2.6.20-stable review


    On Sat, 28 Apr 2007, Bryan WU wrote:
    >
    > You know, because the kernel development is so active and so many stable
    > versions release, it is very hard to decide use which version for mass
    > production, especially some embedded systems which does not often
    > upgrade.

    I actually think that one of the advantages (at least that was the _plan_)
    of having kernel releases every two-to-three months is that for vendors
    who don't upgrade very often, you should always have a choice of few
    kernels to decide on - you can simply decide to go with a less recent
    kernel that you've been testing for a while.

    And with a fairly short release cycle, even if you decide that "hey, we
    just don't know enough about the latest kernel, so let's go with the <n-1>
    release", you won't be _totally_ behind the times. Yeah, you'll be using
    something older, but it will be just two months older, not "totally
    ancient".

    In other words, the fact that the kernel developers cut releases fairly
    often should mean that vendors can much more easily decide on their own
    release cycle _independently_ of the kernel release cycle, because at any
    point in time, you always have *some* kernel release that isn't horribly
    old, and that you can have a few months of knowledge about.

    Compare that to a release cycle of every two years or something (eg a
    major gcc release), where if you're unlucky, you have the choice between
    "recent and all the features, but it's not seen a lot of testing yet", or
    "really quite old and stable, and we'll look bad for packaging it when
    people know there is a much more recent release".

    In that kind of situation, a downstream vendor just doesn't have a lot of
    good choices: delay the release until you know more about the package, or
    ship a really old version, or ship a new and scary one. All three are "big
    choices", and you can just pray you do the right one.

    In contrast, the kernel release cycle has been geared to making those
    choices "small and inconsequential". Right now, you can basically choose
    between any of
    - 2.6.19.7
    - 2.6.20.10
    - 2.6.21.1
    and none of them are horribly old, and you can base your choice on just
    how adventurous you are _and_ on being familiar with two of them.

    For example, I think 2.6.20 was a good release, and so my gut feel is that
    2.6.20.10 is probably preferable over the 2.6.19-based one, but if you
    want to live on the edge, you'd pick 2.6.21.1, and if you want to go for
    having a _loong_ time of being comfy with something, you might decide to
    go with 2.6.16.49 that Adrian has been maintaining.

    In other words, having tight development releases just makes all these
    choices easier. There's more choice, for sure, and that could feel scary,
    but at the same time, it should result in less of a "choice between two
    evils" kind of situation, and more of a "I *can* make an informed choice
    if I just spend some effort on it".

    At least that was the plan. From everything I've heard, most people are
    pretty happy with the 2.6.x development model. You cannot please
    everybody, but the release frequency means that developers feel like they
    can work on relevant stuff all the time, and vendors can always choose
    something that is known stable and not horribly ancient.

    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: 2007-04-28 18:29    [W:3.307 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site