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 07:34:45AM -0800, William Lee Irwin III wrote:
    > On Tue, Jan 04, 2005 at 04:57:38AM -0800, William Lee Irwin III wrote:
    > >> No amount of testing coverage will ever suffice. You're trying to
    > >> empirically establish the nonexistence of something, which is only
    > >> possible to repudiate, and never to verify.
    >
    > On Tue, Jan 04, 2005 at 04:08:10PM +0100, Adrian Bunk wrote:
    > > I claim:
    > > The less and the less invasive patches go into the kernel, the less
    > > likely are breakages.
    > > "enough" shouldn't say "mathematically exactly proven that no
    > > regressions exist" but more something like the pretty small number of
    > > regressions in recent 2.4 kernels.
    >
    > The less that happens, the less likely it is for anything to happen.
    > You're effectively arguing that very little should happen.
    >
    > This cannot be, because pure bugfixing activity alone would overwhelm
    > the limits on levels of activity you endorse. When it comes to design
    > flaws, a single fix for such would swamp the limits on activity you've
    > imposed for a significant portion of a year.

    My opinion is to fork 2.7 pretty soon and to allow into 2.6 only the
    amount of changes that were allowed into 2.4 after 2.5 forked.

    Looking at 2.4, this seems to be a promising model.

    > If you want more stability and fewer regressions, look for methods of
    > getting more peer review for patches, not fewer patches.

    This is only one source of problems, that increases with the amount of
    changes and decreases with the amount of review.

    Another source is the interaction of correct patches with other code. An
    example are (were?) the problems with 4kB stacks on i386 with XFS.

    And then there are issues that are not bugs in the code, but user errors
    that have to be avoided. An example is CONFIG_BLK_DEV_UB in 2.6.9, which
    even the Debian kernel maintainers got wrong in the first kernel
    packages they did put into Debian unstable.

    > -- wli

    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

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