[...]
> > If you want a high quality, tested supported kernel which has been through
> > extensive QA then use kernel for a reputable vendor, or do the QA work
> > yourself or with other people.
> Correct. But this has one problem - it is splitting resources.
> Pushing much of the QA work later in the process means
> that the bugs are found later, that there is more people
> doing this as absolutely necessary and that much more
> communication (and this can be the most important bottleneck)
> is needed as necessary.
Have you got any idea how QA is done in closed environments?
> The need of the VM change is probably a classical example -
> why was it not clear at the 2.4.0-pre1, that the current
> implementation is broken to the point of no repair?
Perhaps because of the same phenomenon that made MS state "WinNT 4.0 has no
flaws" when asked about a nasty problem shortly after release, and it is
now at sp6a + numerous "hotfixes". Like Win2k which now has sp2. Like
Solaris, which still is being fixed. Etc, ad nauseam. Complex software
*has* bugs, bugs which aren't apparent except under unsusual circumstances
are rarely found in the first round of bug chasing.
[...]
> As a user of the vendor's kernel I have no idea what to do
> with a bug.
Report it to the vendor, through the documented channels?
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/