lkml.org 
[lkml]   [2005]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: starting with 2.7
    Adrian Bunk wrote:
    >> The main advantage with stable kernels in the good old days (tm) when 4
    >> and 6 were even numbers was that you knew if something didn't work, and
    >> upgrading to a new kernel inside this stable kernel series had a
    >> relatively low risk of new breakages. This meant one big migration every
    >> few years and relatively easy upgrades between stable series kernels.
    >> Nowadays in 2.6, every new 2.6 kernel has several regressions compared
    >> to the previous one, and additionally obsolete but used code like
    >> ipchains and devfs is scheduled for removal making upgrades even harder
    >> for many users.

    On Sun, Jan 02, 2005 at 05:49:08PM -0500, Bill Davidsen wrote:
    > And there you have my largest complaint with the new model. If 2.6 is
    > stable, it should not have existing features removed just because
    > someone has a new wet dream about a better but incompatible way to do
    > things. I expect working programs to be deliberately broken in a
    > development tree, but once existing features are removed there simply is
    > no stable set of features.

    The presumption is that these changes are frivolous. This is false.
    The removals of these features are motivated by their unsoundness,
    and those removals resolve real problems. If they did not do so, they
    would not pass peer review.


    Adrian Bunk wrote:
    >> There's the point that most users should use distribution kernels, but
    >> consider e.g. that there are poor souls with new hardware not supported
    >> by the 3 years old 2.4.18 kernel in the stable part of your Debian
    >> distribution.

    On Sun, Jan 02, 2005 at 05:49:08PM -0500, Bill Davidsen wrote:
    > The stable and development kernel model worked for a decade, partly
    > because people could build on a feature set and not have that feature
    > just go away, leaving the choice of running without fixes or not
    > running. Since we manage to support 2.2 and 2.4 (and perhaps even 2.0?)
    > I don't see why the definition of "stable" can't simply mean "no
    > deletions from the feature set" and let new features come in for those
    > who want them. Absent that 2.4 will be the last stable kernel, in the
    > sense that features won't be deliberately broken or removed.

    I can't speak for anyone during the times of more ancient Linux history;
    however, developers' dissatisfaction with the development model has been
    aired numerous times in certain fora. It has not satisfactorily served
    developers or users. Users are locked into distro kernels for
    incompatible extensions, and developers are torn between multiple
    codebases.

    This fragmentation of programmer effort is trivially recognizable as
    counterproductive. A single focal point for programmer effort is far
    superior for a development model. If the standard of stability is not
    passed then the code is not ready to be included in any kernel. Then
    the distinction is lost, and each of the fragmented codebases gets a
    third-class effort, and a spurious expenditure of effort is wasted on
    porting fixes and features across numerous different codebases.

    Your estimate of the impact of the feature set upon applications is
    also somewhat exaggerated. The system call ABI has remained backward
    compatible for extended periods of time covering major releases. In
    fact, it would be my personal preference for the next major release to
    signify nothing more than a system call ABI change involving the purging
    of several older, deprecated system call conventions.


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