[lkml]   [2007]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux 2.6.21
    On Thu, 26 Apr 2007, Adrian Bunk wrote:

    > Linus said 2.6.20 was a stable kernel. My impression was that at least
    > two of the regressions from my 2.6.20 regressions list should have been
    > fixed before 2.6.20.
    > They have both been fixed through -stable, but I also remember a quite
    > experienced kernel maintainer running into one of them after 2.6.20 was
    > released and spending half a day tracking it down - and my answer was
    > "known unfixed regression, first reported more than a month ago".

    I think there is an issue with two different things being conflated, and
    this causes real stability problems. 2.6.x is both the first kernel in a
    series that is judged to be "stable" and the kernel that is the split
    between 2.6.x.y and 2.6.x+1. This is a fundamental problem, because it
    means that 2.6.x must have all of the problems that are being debugged by
    the people who understand the areas they are in, because 2.6.x+1 has to
    start so that people who are clueless about all of the areas with
    remaining bugs don't spend their time putting more regressions into their
    submissions for 2.6.x+1.

    It is also a problem because it is easily possible for a problem to exist
    in 2.6.x-rcN which can only be correctly fixed by doing intrusive things,
    but can be papered over in an obviously-safe way. (E.g., the issue with
    legacy interrupt delivery when MSI is enabled). The intrusive patch could
    easily break a bunch of unrelated stuff, so that's no good for 2.6.x-rcN,
    but papering over bugs is no good for mainline. These bugs have to be
    fixed after the split, which means that the version at the fork must
    contain the bug.

    Furthermore, everybody (people reporting bugs, people fixing them, and
    people merging fixes) seem to doze off late in -rc kernels. Having an
    announcement of something with a qualitatively different version wakes
    them up.

    I say have a target of no known regressions in, with 2.6.21 being
    pretty good, and don't count too much on the stability of 3-number kernel

    > And a serious delay of the next regression-merge window due to unfixed
    > regressions might even have the positive side effect of more developers
    > becoming interested in fixing the current regressions for getting their
    > shiny new regressions^Wfeatures faster into Linus' tree.

    I think the "stick" can't be delaying the window, because that's too
    broad. I think it has to be making people who are needed for fixing stuff
    miss the window. People aren't going to go learn a new area of the kernel
    to resolve regressions in it, but they're more likely to keep their own
    area clean so that they get to merge every 2 months instead of every 4.

    > These are just my personal opinions, and other people consider the
    > resulting 2.6.20 and 2.6.21 kernels OK.

    I don't think 2.6.x can be OK, by policy. I think 2.6.20.y got to an OK
    state eventually, which is to say that there's no need now to use a
    2.6.19.y kernel. I think that 2.6.21 isn't OK yet, but I think looking for
    an OK 2.6.21-derived kernel is premature still. Ignoring the version
    scheme entirely, I think the success condition should be that the "latest
    stable version of the Linux kernel" link on is
    always strictly better than all previous links in that spot, and new
    features get there eventually (ideally, within 4 months of hitting
    mainline). I think this is actually possible, although it would require
    changing the policy for this link. And I don't think it requires a change
    in what goes into Linus's git repository when.

    Furthermore, I think we're a lot closer to an OK kernel derived from
    Linus's Apr 25 version than we would be if "2.6.21" had not been released
    at that point. It sounds like more items were resolved in the past few
    days than in the preceding week.

    Incidentally, will you continue to track 2.6.21 regressions against
    2.6.20? You said there was at least one that you haven't sent out, and
    there's been movement on several others since your last report.

    *This .sig left intentionally blank*
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-04-28 01:11    [W:0.031 / U:0.576 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site