[RFC] Kernel version numbering scheme change - Kernel

This is a discussion on [RFC] Kernel version numbering scheme change - Kernel ; On Monday 20 October 2008, Greg KH wrote: > Um, did you not get the memo 3 years ago saying we are changing our > development model and there will not be a 2.7 development series? Well, in theory we ...

+ Reply to Thread
Page 6 of 6 FirstFirst ... 4 5 6
Results 101 to 111 of 111

Thread: [RFC] Kernel version numbering scheme change

  1. Re: [RFC] Kernel version numbering scheme change

    On Monday 20 October 2008, Greg KH wrote:
    > Um, did you not get the memo 3 years ago saying we are changing our
    > development model and there will not be a 2.7 development series?


    Well, in theory we could resume the old numbering scheme again but
    keep the current development model, in effect just inflating the
    version numbers by one level:

    2.6.28-rc1 -> 2.7.0
    2.6.28-rc2 -> 2.7.1
    2.6.28 -> 2.8.0 (perfect -- I've heard people informally call it
    the two-eight release in the past instead of
    two-six-twenty-eight)
    2.6.28.1 -> 2.8.1
    2.6.29-rc1 -> 2.9.0
    2.6.29 -> 2.10.0 or 3.0.0 (depending on your taste)

    This would be entirely consistent with how things have been since 1.0,
    except that we have not had a 2.odd release in a long time.

    Arnd <><
    --
    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/

  2. Re: [RFC] Kernel version numbering scheme change

    On Mon, Oct 20, 2008 at 02:06:48PM -0700, Greg KH wrote:
    > On Mon, Oct 20, 2008 at 11:54:00PM +0300, Felipe Balbi wrote:
    > > On Mon, Oct 20, 2008 at 01:30:33PM -0700, Greg KH wrote:
    > > > > IMHO, having a small number of small digits is the way to go. Using
    > > > > 1 or 2 digits for the major and 1 for the minor is fine. After 3.9, you
    > > > > go to version 4.0. Anyway, there are so many changes between versions
    > > > > these days that any new versions could justify a major change (eg:
    > > > > check the size of the 2.6.27 patch).
    > > > >
    > > > > With versions from 1.1 to 9.9, you can go as high as 88 versions,
    > > > > which is about 22 years of development at current pace. After that,
    > > > > we can simply turn to 10.0 and not break anything.
    > > > >
    > > > > It's also easier for users. Check how many non-kernel techies around you
    > > > > know all 3 digits of the version they use. It's easier to remember 4.3
    > > > > than it is to remember 2.6.27.
    > > >
    > > > I agree that would be nicer, and easier for everyone.

    > >
    > > It's true it would be easier for tracking down and remembering the
    > > version number, but on the other hand, the good thing about this
    > > version number system is that we now 2.6.xx is a rather stable and
    > > complete kernel tree and when we move to 2.7, we know it'll be the start
    > > for the 2.8 kernel series.

    >
    > Um, did you not get the memo 3 years ago saying we are changing our
    > development model and there will not be a 2.7 development series?
    >
    > Damm, I thought I had printed it out and placed it on everyone's chairs.
    > Those pesky cleaners must have picked it up and recycled it, sorry about
    > that...
    >
    > > Just like the migration from 2.4 to 2.5.

    >
    > Please don't bring up the dark ages again, many of us went through
    > things back then that have taken a lot of counseling to be able to get
    > over.


    sorry if i'm developing linux kernel for as long as you are. It's really
    not my business how many hours of counseling you had to attend to get
    over a version numbering change.

    Maybe you still need a bit more, judging by your reply.

    --
    balbi
    --
    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/

  3. Re: [RFC] Kernel version numbering scheme change

    Alex Howells wrote:
    > What I'd love to see any changes integrate would be a simple way to spot
    > -stable releases in the version number (ie: 2.6.16, 2.6.27, those
    > maintained for a "long" time and hopefully by 2.6.16.50+ quite 'bug
    > free') versus the rest of releases sent out on a more regular basis.


    Side note: Long-term maintained kernels like Adrian's 2.6.16.y or
    distro kernels of this sort -> are not 'quite bug free' <-. They are
    only -> quite regression free <-.

    If you want bug fixes, you generally want new kernels. Only a fraction
    of the bug fixes in new kernels are backported to the long-term
    maintained stable kernels. OTOH, also only a fraction of the
    regressions in new kernels is backported to them.
    --
    Stefan Richter
    -=====-==--- =-=- =-=-=
    http://arcgraph.de/sr/
    --
    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/

  4. Re: [RFC] Kernel version numbering scheme change

    Felipe Balbi wrote:
    > On Mon, Oct 20, 2008 at 02:06:48PM -0700, Greg KH wrote:
    >> On Mon, Oct 20, 2008 at 11:54:00PM +0300, Felipe Balbi wrote:
    >>> when we move to 2.7, we know it'll be the start
    >>> for the 2.8 kernel series.

    >> Um, did you not get the memo 3 years ago saying we are changing our
    >> development model and there will not be a 2.7 development series?
    >>
    >> Damm, I thought I had printed it out and placed it on everyone's chairs.
    >> Those pesky cleaners must have picked it up and recycled it, sorry about
    >> that...
    >>
    >>> Just like the migration from 2.4 to 2.5.

    >> Please don't bring up the dark ages again, many of us went through
    >> things back then that have taken a lot of counseling to be able to get
    >> over.

    >
    > sorry if i'm developing linux kernel for as long as you are. It's really
    > not my business how many hours of counseling you had to attend to get
    > over a version numbering change.


    The switch from 2.2/2.3/2.4/2.5 to 2.6.x was not a change of numbering
    scheme, it was a change of the development model. 2.4 and 2.5 were two
    parallel mainlines. 2.6.x is a single mainline, and there won't be two
    mainlines again in any foreseeable future.

    > Maybe you still need a bit more, judging by your reply.


    Or maybe not. You obviously misread his post.
    --
    Stefan Richter
    -=====-==--- =-=- =-=-=
    http://arcgraph.de/sr/
    --
    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/

  5. Re: [RFC] Kernel version numbering scheme change

    On Tue, Oct 21, 2008 at 09:11:52PM +0200, ext Stefan Richter wrote:
    > Felipe Balbi wrote:
    >> On Mon, Oct 20, 2008 at 02:06:48PM -0700, Greg KH wrote:
    >>> On Mon, Oct 20, 2008 at 11:54:00PM +0300, Felipe Balbi wrote:
    >>>> when we move to 2.7, we know it'll be the start
    >>>> for the 2.8 kernel series.
    >>> Um, did you not get the memo 3 years ago saying we are changing our
    >>> development model and there will not be a 2.7 development series?
    >>>
    >>> Damm, I thought I had printed it out and placed it on everyone's chairs.
    >>> Those pesky cleaners must have picked it up and recycled it, sorry about
    >>> that...
    >>>
    >>>> Just like the migration from 2.4 to 2.5.
    >>> Please don't bring up the dark ages again, many of us went through
    >>> things back then that have taken a lot of counseling to be able to get
    >>> over.

    >>
    >> sorry if i'm developing linux kernel for as long as you are. It's really
    >> not my business how many hours of counseling you had to attend to get
    >> over a version numbering change.

    >
    > The switch from 2.2/2.3/2.4/2.5 to 2.6.x was not a change of numbering
    > scheme, it was a change of the development model. 2.4 and 2.5 were two
    > parallel mainlines. 2.6.x is a single mainline, and there won't be two
    > mainlines again in any foreseeable future.


    at least now you gave me the reasons and I got the point. Thanks for
    clarifying.

    --
    balbi
    --
    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/

  6. Re: [RFC] Kernel version numbering scheme change

    Greg KH wrote:
    > What do you mean? The .y marking of releases right now doesn't show you
    > this?


    Sorry, perhaps I wasn't clear with regards "bugs" vs. "regressions" as
    someone else pointed out in a reply

    > The "longevity" of a release series has no real correlation to it's "bug
    > free"ness of it in any strict sense of the word. Just look at the
    > percentage of fixes in any normal release for "bugs" to get a concrete
    > feel for that (hint, it's in the thousands).


    Okay, sure.

    > What is frustrating about it right now? It is _strongly_ recommended
    > that if you are following the kernel.org tree, for you to rely on the
    > -stable releases. It is best if you can upgrade to the latest branch of
    > the stable releases when they come out, moving to the latest major
    > release when possible, as you usually only have a month or so when they
    > start up before the previous branch's stable tree stops being
    > maintained.


    That was what I was inviting people to solve, actually.

    What I don't think is 100% clear right now is which kernels are still
    actively maintained, and which are not. When does a kernel become EoL?
    This is different for things like 2.6.16.x and 2.6.27.x to others?
    Perhaps this could be a part of the version numbering scheme?

    I'm speaking only from personal experience here, but have had hideous
    issues getting a "one kernel fits all" solution for boxes at work.
    Requirements for me to put a kernel on a given server would be:

    * supports the hardware
    * no security holes [in options I enable]
    * works reliably, under load/stress.

    Now I wouldn't call myself an 'expert' by any means, so please forgive
    me in advance if I'm wrong in any of the following...

    A lot of the problems I've spotted have been traced (kind thanks to
    Daniel Drake, Francois Romieu and others) to the network drivers,
    particularly forcedeth/r8169 NICs actually but some e1000 stuff too.
    Filing bugs and getting those issues fixed for everyone is important,
    but sometimes the question remains "Why upgrade when 2.6.16.xx meets the
    criteria above? Can we be sure 2.6.24.xx will be as stable?".

    There is nothing stopping you setting aside a couple of boxes and
    checking the latest -stable for testing purposes, for planning where you
    *will* go when 2.6.16.xx stops being maintained, and filing any bugs you
    spot along the way to try and contribute to this effort.

    This mostly came about because we have a large-ish number of boxes
    currently tracking 2.6.16.xx and that works *very* well for us.
    Discovering that 2.6.16 would be maintained in such a way was tough
    though as I'm only a fairly recent subscriber to LKML.

    So with regards to supported kernels, the following springs to mind:

    * how long is kernel 2.6.xx supported?
    * is kernel 2.6.xx one of the "longer term" supported ones?
    * what are the requirements for a maintainer to push a
    new release, a la 2.6.xx.yy? Is it based on time elapsed,
    severity of any fixes included?
    * how do we define "support" in this context?
    does it mean security problems discovered/fixed *after*
    development focus has moved on to new stuff is backported?
    does it mean [critical] bug fixes? regression fixes?

    > Some times I think I need to put up a big .SVG drawing of all of the
    > releases, showing which ones are currently being maintained, and which
    > ones aren't just to make it easier. I wonder if firefox could show it
    > properly, would that help out?


    It would Thanks for your response.

    Alex
    --
    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/

  7. Re: [RFC] Kernel version numbering scheme change

    On Tue, 21 Oct 2008 20:52:02 BST, Alex Howells said:
    > Requirements for me to put a kernel on a given server would be:


    > * supports the hardware

    The problem is that "supports" is often a fuzzy jello-like substance you
    try to nail to a tree. You mention the R8169 and e1000 drivers - if they
    bring the device up, but have issues under corner cases, is that "supports"
    or not?

    > * no security holes [in options I enable]

    Similarly for "no security holes". At *BEST*, you'll get "no *known* *major*
    security holes", unless you feel like auditing the entire source tree. There's
    a whole slew of bugs that we can't even agree if they *are* security bugs or
    just plain bugs - see Linus's rant on the subject a few months back.

    > * works reliably, under load/stress.

    And you win the trifecta - I don't think we've *ever* shipped a Linux kernel
    that worked reliably under the proper "beat on the scheduler/VM corner case"
    load/stress testing. Again, the best you can hope for is "doesn't fall over
    under non-pathological non-corner-case loads when sufficient resources are
    available so the kernel has a fighting chance". Doing 'make -j100' on a
    single Core2 Duo is gonna be painful, no matter what.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFI/na0cC3lWbTT17ARAl/NAKDqt+/Z3WbNk8obIJGE7S+qDQVVqQCfabIk
    VroOeOk36IVlE9RW6xxlpwo=
    =wAI5
    -----END PGP SIGNATURE-----


  8. Re: [RFC] Kernel version numbering scheme change

    On Tue, 21 Oct 2008 20:41:24 -0400, you wrote:

    >On Tue, 21 Oct 2008 20:52:02 BST, Alex Howells said:
    >> Requirements for me to put a kernel on a given server would be:

    >
    >> * supports the hardware

    >The problem is that "supports" is often a fuzzy jello-like substance you
    >try to nail to a tree. You mention the R8169 and e1000 drivers - if they
    >bring the device up, but have issues under corner cases, is that "supports"
    >or not?
    >
    >> * no security holes [in options I enable]

    >Similarly for "no security holes". At *BEST*, you'll get "no *known* *major*
    >security holes", unless you feel like auditing the entire source tree. There's
    >a whole slew of bugs that we can't even agree if they *are* security bugs or
    >just plain bugs - see Linus's rant on the subject a few months back.
    >
    >> * works reliably, under load/stress.

    >And you win the trifecta - I don't think we've *ever* shipped a Linux kernel
    >that worked reliably under the proper "beat on the scheduler/VM corner case"
    >load/stress testing. Again, the best you can hope for is "doesn't fall over
    >under non-pathological non-corner-case loads when sufficient resources are
    >available so the kernel has a fighting chance".


    >... Doing 'make -j100' on a
    >single Core2 Duo is gonna be painful, no matter what.


    Not painful at all, make -j100 is four seconds faster than a make -j5 on
    a Core2Duo here with slamd64-12.1 (real: 3m21 vs 3m21).

    Grant.
    --
    http://bugsplatter.id.au
    --
    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/

  9. Re: [RFC] Kernel version numbering scheme change

    Hey Valdis

    >> Requirements for me to put a kernel on a given server would be:

    >
    >> * supports the hardware

    > The problem is that "supports" is often a fuzzy jello-like substance you
    > try to nail to a tree. You mention the R8169 and e1000 drivers - if they
    > bring the device up, but have issues under corner cases, is that "supports"
    > or not?


    Oh agreed, this is all very "use case" specific. I'm making all of the
    following statements based on the specific hardware we use, and assuming
    'stability' based on the kernel/hardware passing a number of tests.

    >> * no security holes [in options I enable]

    > Similarly for "no security holes". At *BEST*, you'll get "no *known* *major*
    > security holes", unless you feel like auditing the entire source tree. There's
    > a whole slew of bugs that we can't even agree if they *are* security bugs or
    > just plain bugs - see Linus's rant on the subject a few months back.


    Agreed. No *known* *major* security holes is fine here.

    >> * works reliably, under load/stress.

    > And you win the trifecta - I don't think we've *ever* shipped a Linux kernel
    > that worked reliably under the proper "beat on the scheduler/VM corner case"
    > load/stress testing. Again, the best you can hope for is "doesn't fall over
    > under non-pathological non-corner-case loads when sufficient resources are
    > available so the kernel has a fighting chance". Doing 'make -j100' on a
    > single Core2 Duo is gonna be painful, no matter what.


    Well the typical tests outlined above are:

    * random size file creation/deletion, lots of files
    * memory allocation, and freeing up again
    * stressing the CPU a bit with one process, then
    forking 25-50 processes to (trivially) test scheduler
    * testing network I/O by rapidly/concurrently fetching
    many small files via HTTP, and a few large ones.

    The end goal is simply to get a server which doesn't crash under
    "normal" operating conditions. The bugs I referred to in
    e1000/forcedeth and r8169 either stop it PXE booting (a requirement for
    our environment!) or can *easily* be made to oops / stop working.

    Alex

    --
    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/

  10. Re: [RFC] Kernel version numbering scheme change

    On Wed, 22 Oct 2008 09:58:06 +0100
    Alex Howells wrote:

    > > And you win the trifecta - I don't think we've *ever* shipped a Linux kernel
    > > that worked reliably under the proper "beat on the scheduler/VM corner case"
    > > load/stress testing. Again, the best you can hope for is "doesn't fall over


    Upstream kernels can be a bit iffy especially on 32bit boxes with lots
    of RAM. The enterprise vendor kernels have had months of tuning on high
    load tests and behave far better than upstream. If you are running 32bit
    and > 2GB of RAM I wouldn't even bother with upstream kernels to be
    honest - pick one of the enterprise distributions or free repackagings
    thereof. Better yet go 64bit

    At minimum with 2.6.x under high load you also need Arjan van de Ven's
    patches to fix the ioprio mess - and god knows why those haven't been
    accepted upstream given they make a huge difference to performance and
    load handling.

    http://lkml.org/lkml/2008/10/2/297

    > > under non-pathological non-corner-case loads when sufficient resources are
    > > available so the kernel has a fighting chance". Doing 'make -j100' on a
    > > single Core2 Duo is gonna be painful, no matter what.


    Turn on strict overcommit and the box will degrade sanely and then if
    need be start erroring things with out of memory before it goes kersplat.
    That was a feature added a long time ago by Red Hat and then merged
    upstream because serious business users of Linux need better guarantees
    than the base kernel defaults.

    If you have a non AMD processor without an IOMMU and are doing high
    amounts of I/O make sure your I/O devices are 64bit capable - particular
    watch SATA as most ATA hardware that isn't AHCI is 32bit constrained.

    Alan
    --
    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/

  11. Re: [RFC] Kernel version numbering scheme change

    Alex Howells wrote:
    > So with regards to supported kernels, the following springs to mind:
    >
    > * how long is kernel 2.6.xx supported?
    > * is kernel 2.6.xx one of the "longer term" supported ones?
    > * what are the requirements for a maintainer to push a
    > new release, a la 2.6.xx.yy? Is it based on time elapsed,
    > severity of any fixes included?
    > * how do we define "support" in this context?
    > does it mean security problems discovered/fixed *after*
    > development focus has moved on to new stuff is backported?
    > does it mean [critical] bug fixes? regression fixes?


    That's all quite simple to answer with a firm "depends".

    1. Remember, it's all volunteer work (by companies and individuals).

    2. Watch the release announcements and changelogs to learn about the
    lifetimes of -stable lines (they vary due to circumstances) and
    about what goes in into these lines. There are also some bits in
    Documentation/stable_kernel_rules.txt.

    Among else, it depends on volunteered manpower for patch verification
    and even on sheer coincidence (somebody needs to be aware that an issue
    is relevant to an active -stable line) whether a fix goes into -stable
    or not.

    Circumstances which lead to a -stable line remaining active for longer
    than usual typically boil down to the motives of an individual developer
    who picks up maintenance, like Adrian happened to do with 2.6.16.y and
    plans to repeat with 2.6.27.y, or like Greg kept/ keeps 2.6.25.y active
    alongside 2.6.26.y because it's directly useful to other work of his, AFAIU.

    If you are interested in more structured release policies, you shouldn't
    hesitate to have a look at vendor kernel lines.
    --
    Stefan Richter
    -=====-==--- =-=- =-==-
    http://arcgraph.de/sr/
    --
    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/

+ Reply to Thread
Page 6 of 6 FirstFirst ... 4 5 6