How to improve the quality of the kernel?

On Sun, Jun 17, 2007 at 03:17:58PM +0200, Michal Piotrowski wrote:
On 17/06/07, Adrian Bunk <bunk@xxxxxxxxx> wrote:
...
Fine with me, but:

There are not so simple cases like big infrastructure patches with
20 other patches in the tree depending on it causing a regression, or
even worse, a big infrastructure patch exposing a latent old bug in some
completely different area of the kernel.

It is different case.

"If the patch introduces a new regression"

introduces != exposes an old bug

My remark was meant as a note "this sentence can't handle all
regressions" (and for a user it doesn't matter whether a new
regression is introduced or an old regression exposed).

It could be we simply agree on this one. ;-)

Removal of 20 patches will be painful, but sometimes you need to
"choose minor evil to prevent a greater one" [1].

And we should be aware that reverting is only a workaround for the real
problem which lies in our bug handling.
...

And this is something I want to emphasize again.

How can we make any progress with the real problem and not only the
symptoms?

There's now much money in the Linux market, and the kernel quality
problems might result in real costs in the support of companies like
IBM, SGI, Redhat or Novell (plus it harms the Linux image which might
result in lower revenues).

If [1] this is true, it might even pay pay off for them to each assign
X man hours per month of experienced kernel developers to upstream
kernel bug handling?

This is just a wild thought and it might be nonsense - better
suggestions for solving our quality problems would be highly welcome...

cu
Adrian

[1] note that this is an "if"

--

"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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: How to improve the quality of the kernel?
    ... >> 20 other patches in the tree depending on it causing a regression, ... > "If the patch introduces a new regression" ... >> problem which lies in our bug handling. ... There's now much money in the Linux market, and the kernel quality ...
    (Linux-Kernel)
  • MPT Fusion SAS 2.6.31 regression, crash on heavy load
    ... While on 2.6.30.5 MPT SAS controller worked fine, on 2.6.31 it fails on heavy ... x86, Sun Fire X4100, 8 GB RAM, PAE kernel enabled, module loaded with default ... I upgrade BIOS, LSI controller BIOS to latest version, it didn't fix the bug. ... regression and i guess dangerous regression (causing data loss on high ...
    (Linux-Kernel)
  • Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))
    ... >> The problem is that we aren't able to handle the many regression reports ... >> spent much time and energy in writing a good bug report. ... >> source of quality problems in the Linux kernel. ...
    (Linux-Kernel)
  • Re: Suspend/resume regression between 2.6.26 and 2.6.27-rc1
    ... this is the ACPI regression test result based on the latest ACPI test branch. ... chipset, 64-bit kernel). ... The system will be rebooted when pressing power button after the box ... After using the git-bisect it is confirmed that the commit ...
    (Linux-Kernel)
  • Re: [PATCH] x86/paravirt: revert exports to restore old behaviour
    ... Christoph Hellwig objects to this patch on the grounds that modules ... CONFIG_PARAVIRT and non-CONFIG_PARAVIRT configurations. ... Current practice in the kernel is that when something that should not be ... It cannot be a regression since the kernel does not have a stable API ...
    (Linux-Kernel)