Re: My thoughts on the "new development model"

From: John Richard Moser (nigelenki_at_comcast.net)
Date: 10/28/04

  • Next message: Alessandro Amici: "Re: massive cross-builds without too much PITA" 
    Date:	Thu, 28 Oct 2004 12:14:42 -0400
To: michael@optusnet.com.au

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    michael@optusnet.com.au wrote:
    | John Richard Moser <nigelenki@comcast.net> writes:
    | [ .. lots of stuff .. ]
    |
    |>Let's make 2.7 what 2.6 is now (a relatively stable kernel that gets
    |>relatively stable feature enhancements continuously), rather than what
    |>2.5 was (a hell of a lot of patches and then a hell of a lot of
    |>debugging), and make 2.6 more restrictive than 2.4 in that it should be
    |>strictly bugfixes (including security bugs) and no backported drivers or
    |>features.
    |
    |
    | There seems to be a lot of strange notions on this concept of 'stable'.
    | The only thing that makes a kernel 'stable' is time. Not endless
    | bugfixes. Just time. The idea of stable software is software that not
    | going to give you any suprises, software that you can trust.
    |

    Right. Bugfixing the "Stable" branch ONLY will make sure it does not
    surprise you with sudden new features (which may surprise you by. . .
    breaking your own patches!).

    | That's NOT the same as bug free software. For a start, there's no such
    | thing.

    5-50 per KLOC.

    | For another, many bugs are perfectly acceptable in a production
    | environment as long as they're not impacting. (The linux kernel is a
    | very large piece of work. Few installations would use even 20% of the
    | total kernel functionality).
    |
    | If you want a stable kernel version, pick one (almost any one will
    | do). Test the hell of out it with your application(s). If it fails,
    | fix the bug, or pick a different version. rinse, repeat.
    |
    | Now you've got a kernel that tests clean with your app. DON'T
    | CHANGE IT!!
    |
    | Ta-Dah! You've got a stable kernel.
    |

    That if I keep my realtime patches or my security enhancements or my new
    drivers or my new filesystems on and don't continuously upgrade will
    cause me to stagnate and be left behind and ignored.

    I've already heard rumors (very few, and they've been squashed) of
    GrSecurity being abandoned. The authors of both PaX and Gr are both
    active, they're just spinning on 2.6.7.

    Do you see the scenario occuring here? Their project is obviously
    inferior in many peoples' minds because it's not the latest
    hot-off-the-LKML 2.6 kernel. Indeed, many security fixes in (soon to
    be) 2.6.10 aren't in 2.6.7, which could provide known ways to easily
    slip straight past PaX and Gr (I haven't done my research, but this is
    not a hollow scenario).

    | Now why would you change it? The only possible reasons
    | are that your testing was terrible and you missed a bug,
    | in which case you can go back to step 1, or that you
    | want a new feature. In which case you can go back to
    | step 1.
    |
    | That wasn't too hard, was it. Even better, you didn't see
    | anything in there about 2.6 v 2.7 or other such fluff.
    |
    | Michael.
    |

    - --
    All content of all messages exchanged herein are left in the
    Public Domain, unless otherwise explicitly stated.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.6 (GNU/Linux)
    Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

    iD8DBQFBgRrxhDd4aOud5P8RArUKAJ97tfBLjXCGYQx1DiR0Iul0mwa2FgCfXZMS
    vi6YYB8ik6IWO441jZPX5oI=
    =YvZq
    -----END PGP SIGNATURE-----
    -
    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/

  • Next message: Alessandro Amici: "Re: massive cross-builds without too much PITA"

    Relevant Pages

    • Re: This is [Re:] How to improve the quality of the kernel[?].
      ... The problem are more social problems like patches Andrew has never heard ... The accepted industry standard for bug counts is basically one bug per a ... We cannot get a regression free or even bug free kernel. ... able to handle all incoming bug reports is IMHO a worthwhile and not ...
      (Linux-Kernel)
    • Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project
      ... They're only seeing janitorial-style patches hit ... a lot of the trivial patches don't come across the janitors list ... people involved with kernel development, ... fixing a bug. ...
      (Linux-Kernel)
    • Re: [PATCH] new CSA patchset for 2.6.8
      ... Please don't send patches as attachments, and please don't send more than ... one patch per email. ... judging how useful this feature is to Linux implementors and how well this ... > functional kernel. ...
      (Linux-Kernel)
    • Re: Development tree, PLEASE?
      ... shipping an older kernel, and hasn't hit that particular bug yet. ... SuSE's kernels suffer the same problem of too many patches I ... You can't complain about 'too many patches' in a distro kernel these days. ... or rh-specific feature. ...
      (Linux-Kernel)
    • Re: Stop the Linux kernel madness
      ... >> This is absolutely not our problem and we don't know who to contact at SuSE to fix ... > Are you referring to userspace applications which fail under Suse's kernel, ... > could be a bug in the Suse changes, ... > suse are sitting on 1500 patches is a combination of: ...
      (Linux-Kernel)