[lkml]   [2005]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFD: Kernel release numbering
    On Thu, 2005-03-03 at 00:21 -0500, Dave Jones wrote:
    > On Wed, Mar 02, 2005 at 08:38:12PM -0800, Andrew Morton wrote:
    > > Dave Jones <> wrote:
    > > >
    > > > On Wed, Mar 02, 2005 at 04:00:46PM -0800, Linus Torvalds wrote:
    > > >
    > > > > I would not keep regular driver updates from a 2.6.<even> thing.
    > > >
    > > > Then the notion of it being stable is bogus, given how many regressions
    > > > the last few kernels have brought in drivers. Moving from 2.6.9 -> 2.6.10
    > > > broke ALSA, USB, parport, firewire, and countless other little bits and
    > > > pieces that users tend to notice.
    > >
    > > Grump. Have all these regressions received the appropriate level of
    > > visibility on this mailing list?
    > For the most part these things are usually known about by their upstream
    > authors. To give an example: ALSA update in 2.6.10 broke sound for a
    > bunch of IBM thinkpads. As it turns out there are quite a lot of these
    > out there, so when I released a 2.6.10 update for Fedora, bugzilla lit
    > up like a christmas tree with "Hey, where'd my sound go?" reports.
    > (It was further confused by a load of other sound card problems, but
    > thats another issue). This got so out of control, Alan asked the ALSA
    > folks to take a look, and iirc Takashi figured out what had caused the
    > problem, and it got fixed in the ALSA folks tree, and subsequently, in 2.6.11rc.
    > Now, during all this time, there hadn't been any reports of this problem
    > at all on Linux-kernel. Not even from Linus' tree, let alone -mm.
    > Which amazes me given how widespread the problem was.

    There is not much the ALSA developers can do about this, because we just
    do not have access to the 1000s of hardware varieties out there, and
    vendors are inexplicably loath to give out any docs on something as
    simple as a cheap shitty laptop AC97 codec.

    The usual pattern that leads to a regression like the Thinkpad issue is
    that a user reports a bug, a fix is merged, the user reports the problem
    is fixed on $FOO hardware, then a week later we are deluged with reports
    that $BAR hardware is now broken.

    Catching a problem like this before it gets out the door would require
    access to 1000s of laptops, unlimited time, and reasonable hardware
    documentation. Chances are we would still miss something. IOW it's

    The *only* solution for these kinds of driver regressions is to get more
    people to test the release candidates. "Being more careful" will not
    help, because we just don't have access to all of the hardware.


    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: 2005-03-22 14:10    [W:0.045 / U:44.048 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site