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
    Jeff V. Merkey wrote:
    >
    > __Stable__ would be a good thing. The entire 2.6 development has been a
    > disaster from
    > a stability viewpoint. I have to maintain a huge tree of patches in
    > order to ship appliance
    > builds due to the lack of stability for 2.6. I think that the even
    > number releases will take longer but it's worth the wait.
    >
    > Jeff

    Linus's release cycle estimate might be optimistic. :)

    I'm seeing lots more bug reports recently than I care to see. :(

    > Linus Torvalds wrote:
    >
    >> This is an idea that has been brewing for some time: Andrew has mentioned
    >> it a couple of times, I've talked to some people about it, and today
    >> Davem
    >> sent a suggestion along similar lines to me for 2.6.12.
    >>
    >> Namely that we could adopt the even/odd numbering scheme that we used
    >> to do on a minor number basis, and instead of dropping it entirely
    >> like we did, we could have just moved it to the release number, as an
    >> indication of what was the intent of the release.
    >>
    >> The problem with major development trees like 2.4.x vs 2.5.x was that
    >> the release cycles were too long, and that people hated the back- and
    >> forward-porting. That said, it did serve a purpose - people kind of
    >> knew where they stood, even though we always ended up having to have
    >> big changes in the stable tree too, just to keep up with a changing
    >> landscape.
    >>
    >> So the suggestion on the table would be to go back to even/odd, but do
    >> it at the "micro-level" of single releases, rather than make it a two-
    >> or three-year release cycle.
    >>
    >> In this setup, all kernels would still be _stable_, in the sense that we
    >> don't anticipate any real breakage (if we end up having to rip up so much
    >> basic stuff that we have to break anything, we'd go back to the 2.7.x
    >> kind
    >> of numbering scheme). So we should fear odd releases, but track them,
    >> to make sure that they are good (if you don't track them, and problems
    >> won't be fixed in the even version either)
    >>
    >> But we'd basically have stricter concerns for an even release, and in
    >> particular the plan would be that the diff files would alternate between
    >> bigger ones (the 2.6.10->11 full diff was almost 5MB) and smaller ones (a
    >> 2.6.11->12 release would be a "stability only" thing, and hopefully the
    >> diff file would be much smaller).
    >>
    >> We'd still do the -rcX candidates as we go along in either case, so as
    >> a user you wouldn't even _need_ to know, but the numbering would be a
    >> rough guide to intentions. Ie I'd expect that distributions would
    >> always try to base their stuff off a 2.6.<even> release.
    >>
    >> It seems like a sensible approach, and it's not like the 2.4.x vs 2.5.x
    >> kind of even/odd thing didn't _work_, the problems really were an
    >> issue of
    >> too big granularity making it hard for user and developers alike. So I
    >> see
    >> this as a tweak of the "let's drop the notion althogether for now"
    >> decision, and just modify it to "even/odd is meaningful at all levels".
    >>
    >> In other words, we'd have an increasing level of instability with an
    >> odd release number, depending on how long-term the instability is.
    >>
    >> - 2.6.<even>: even at all levels, aim for having had minimally
    >> intrusive patches leading up to it (timeframe: a week or two)
    >>
    >> with the odd numbers going like:
    >>
    >> - 2.6.<odd>: still a stable kernel, but accept bigger changes leading
    >> up to it (timeframe: a month or two).
    >> - 2.<odd>.x: aim for big changes that may destabilize the kernel for
    >> several releases (timeframe: a year or two)
    >> - <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote
    >> the kernel to be a microkernel using a special message-passing
    >> version of Visual Basic. (timeframe: "we expect that he will be
    >> released from the mental institution in a decade or two").
    >>
    >> The reason I put a shorter timeframe on the "all-even" kernel is
    >> because I
    >> don't want developers to be too itchy and sitting on stuff for too
    >> long if
    >> they did something slightly bigger. In theory, the longer the better
    >> there, but in practice this release numbering is still nothing but a hint
    >> of the _intent_ of the developers - it's still not a guarantee of "we
    >> fixed all bugs", and anybody who expects that (and tries to avoid all
    >> odd release entirely) is just setting himself up for not testing - and
    >> thus bugs.
    >>
    >> Comments?


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