lkml.org 
[lkml]   [2005]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: starting with 2.7
    On Tue, Jan 04, 2005 at 06:33:48AM +0100, Willy Tarreau wrote:
    >> These two problems are solvable with the same solution : no rc anymore.
    >> I agree with Ted. A version every week or 2 weeks is good. People will
    >> run random versions, some will report problems, others not. After that,
    >> you know the differences between exact releases, you don't have to parse
    >> 28 MB changes. And you can also ask them to upgrade or downgrade and
    >> quickly find where the bug entered.

    On Tue, Jan 04, 2005 at 04:21:36PM +0100, Adrian Bunk wrote:
    > This was the model for development kernels, and it's usable for
    > development kernels.
    > The problem is that 28 MB in 9 weeks are 3 MB of changes every week.
    > With such a weekly model, I fear the weekly kernels would be of very
    > varying quality and never fully stable. Up to 2.4, kernel.org kernels
    > were usually a good choice, but with such a model the only usable
    > kernels in production environments will be distribution kernels that
    > will contain the mixture of at least three "stable" kernel for getting a
    > usable kernel.

    You could in principle base version numbers on external influences. In a
    5-point decimal system, then 2.6.x.y.z would be released daily, 2.6.x.y.0
    released every 10 days, 2.6.x.0.0 released every 100 days, and 2.7.0.0.0
    released after 1000 days, and so on.

    Similarly for patches instead of days; an 8-point decimal system could
    be released based on the number of patches merged. 2.6.u.v.w.x.y.z
    would be "released" for every patch merged, 2.6.u.v.w.x.y.0 released
    for every 10 patches, 2.6.u.v.w.x.0.0 released for every 100 patches,
    2.6.u.v.w.0.0.0 for every 1000 patches, 2.6.u.v.0.0.0.0 released after
    10000 patches, 2.6.u.0.0.0.0.0 released after 100000 patches, and
    2.7.0.0.0.0.0 released after 1000000 patches. Or perhaps a natural
    number merely counting the number of patches merged suffices.

    In both decimal systems, 0 <= u, v, w, x, y, z < 10.

    This will ultimately be defeated by anticipatory behavior regarding
    magic numbers (lots of 0's) and divergent trees, though I actually sort
    of like the 8-point decimal system based on patches merged or otherwise
    counting the number of patches merged, since it would provide a method
    of referring to all states of the tree, enabling binary search for bugs.

    But I highly doubt anything of these kinds will happen, and they're
    largely orthogonal to the issue of users being scared of how big the
    tree has gotten and not being able to understand that large numbers of
    patches must be interpreted relative to the size of the codebase
    instead of in absolute terms.


    -- wli
    -
    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:09    [W:2.086 / U:0.944 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site