[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200805010553.50264.elendil@planet.nl>
Date: Thu, 1 May 2008 05:53:48 +0200
From: Frans Pop <elendil@...net.nl>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: rjw@...k.pl, w@....eu, davem@...emloft.net,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
jirislaby@...il.com
Subject: Re: Slow DOWN, please!!!
Linus Torvalds wrote:
> IOW, I argue that the high speed of merging very much is a big part of
> what gives us quality in the end. It may result in bugs along the way, but
> it also results in fixes, and lots of people looking at the result (and
> looking at it in *context*, not just as a patch flying around).
The main problem as I see it is with the huge number of hard, confirmed bugs
that are *not* getting fixed.
With the current development model, developers only really care about
current regressions. In a large part this is due to the excellent work of
Rafael with his tracking of regressions since the previous release.
But it does mean older regressions fall by the wayside, even if they've been
confirmed, bisected and the submitter is responsive.
For a while Natalie Protasevich did some work on trying to get attention for
older regressions, but that effort seems to have died out.
Two concrete examples from my personal experience:
- http://bugzilla.kernel.org/show_bug.cgi?id=9749; the error:
sysctl table check failed:
/dev/parport/parport0/devices/ppdev0/timeslice Sysctl already exists
First reported for 2.6.24-rc5, just now confirmed with 2.6.25
Acknowledged by maintainer, but no follow-up [1].
- http://bugzilla.kernel.org/show_bug.cgi?id=9310; the error:
completely blank console with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY set when
framebuffer is active, but no VGA=xxx parameter is passed
First reported for 2.6.23, confirmed for 2.6.24-rc6, almost certainly
still present in 2.6.25
Acknowledged by maintainer, but no follow-up despite later pings.
Another issue is that sometimes developers really are too eager to get their
changes into mainline even when there are known issues or when they know in
their heart that the changes have not received enough testing.
Example is a a scheduler change [2] that causes a completely reproducible
regression (music skips and key repeats) on my box with one specific
workload. Ingo and Peter have been great doing debugging after I reported
it for 2.6.25-rc8 and it was reverted just before the release, but I was
very surprised to see the patch resubmitted for 2.6.26 without the
regression being resolved first.
It is now confirmed to still be there and there has been additional effort
on it, but so far without result.
This really is nothing against Ingo (in fact he is in my experience one of
the most responsive developers when issues are reported), but in this case
I personally do feel the patch should not have been reintroduced into
mainline before the regression had been sorted out.
Cheers,
FJP
[1] Update: Eric just added a nice reply in Bugzilla.
[2] http://bugzilla.kernel.org/show_bug.cgi?id=10428
http://lkml.org/lkml/2008/4/19/181
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists