lkml.org 
[lkml]   [2005]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: RFD: Kernel release numbering
    On Thu, 3 Mar 2005, Neil Brown wrote:

    > On Wednesday March 2, davem@davemloft.net wrote:
    >> On Wed, 02 Mar 2005 23:46:22 -0500 Jeff Garzik <jgarzik@pobox.com> wrote:
    >>
    >>> If Linus/DaveM really don't like -pre/-rc naming, I think 2.6.x.y is
    >>> preferable to even/odd.
    >>
    >> All of these arguments are circular. If people think that even/odd
    >> will devalue odd releases, guess what 2.6.x.y will do? By that line
    >> of reasoning nobody will test 2.6.x just the same as they aren't
    >> testing 2.6.x-rc* right now.
    >
    > I think there is a qualitative difference.
    > 2.6.x is the end of a line that 2.6.x-rc* leads up to. There is a
    > clear end. "I will test when it gets to the end".
    >
    > 2.6.x.y doesn't. If the releases are quick (daily if there is
    > anything to release) then there is no clear end to the list, just a
    > beginning. There may never be a 2.6.x.1 for some values of x, so
    > people won't be able to wait for the .1 or the .2 release. They will
    > have to just take what is available when they want to upgrade.

    as one of the users since the mid 2.0 series. I really think this is the
    best approach.

    with any 'stable' kernel series I have always had to wait at least a few
    days from the release to allow people to report brown-bag problems, and
    then I've needed to test it on my particular hardware to make sure there
    are no driver gotcha's that happen to bite my configuration, then I can
    deploy (either immediatly if it's a security issue, or after load testing
    if it's not)

    the 2.6.odd/even won't change this at all

    the 2.6.x.y will leave me needing to do the same thing for each new x, but
    any new .y releases that take place should be able to follow a more rapid
    path as they will probably have _very_ few changes in them (i.e. no driver
    updates that aren't significant bugfixes). and the ability to do more then
    one .y release if nessasary without confusing people is definantly an
    advantage over the odd/even approach

    > If we want to stop people from waiting for a final release before they
    > test, we need to make sure there isn't a (recognisable in advance)
    > final release.

    good point

    David Lang

    --
    There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
    -- C.A.R. Hoare
    -
    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.032 / U:31.436 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site