Re: Slow DOWN, please!!!

[Frans Pop <elendil@planet.nl>]

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