Here we have the crux of the matter: there are some standard kernel
features, e.g., ISDN, RAID, NFS, that have at times fallen into
disrepair, because nobody was actively developing/maintaining them, or
development was occurring off this list and not syncing up in a timely
manner. This was true of at least ISDN and NFS in the 2.1.x series.
Linus has insisted that large subsystem patches be accompanied by a
subsystem maintainer. I don't blame him; this is as it should be,
because the alternatives are not sustainable. The short-term effect,
however, has been to cause serious users of these features, as well as
several distributions, to use "non-standard patches" against stable
kernels. It behooves us to ensure that all features have
maintainers, and preferably several people who have a thorough
understanding of the code. It also behooves us to test development
kernels widely, before the code freezes are announced.
In the interest of putting my money and time where my mouth is, the
parts for my SMP box just arrived today. For US$1500 I have a fast box that
will be devoted exclusively to testing development releases. Anyone
using Linux in production, or considering it, should probably be
doing the same.
Unfortunately, I am only just beginning to understand many kernel
issues, and my day job keeps me extremely busy. At best, I expect to gain
enough of a local understanding of various features and subsystems to
correctly identify problems, and make an attempt at a fix.
> If Alan and Linus were to go along with my suggestion and accept only bug
> fixes into 2.2, there might be fewer 2.2.x releases to trip you up, and
> each one would have less code changed so the old patches would be more
> likely to work.
As the development cycle shortens this will become more feasible. But
the reality is PC hardware changes constantly: ACPI, USB, ..., the list
is very long. Are you really suggesting that we only support new
processor variants or chipsets (like Athlon or the Intel 810/820) in
the development kernels until the next stable release?
It would be sufficient, I think, if the individual bug fixes and
updates were more transparent, particularly in the stable series. One
of the virtues of having individual patch sets committed into a system
like CVS is that even if there are ordering dependencies and individual
patches doesn't apply cleanly, at least I can make some progress in
understanding what is going on. As it is, a few different patches
touching a file like fs/buffer.c quickly confuses me (and apparently
others). Witness the number of requests on this list for Alan to break
out the 2.2.12 fix from 2.2.13pre* and put it in the 2.2.12 errata.
Whether with Larry's tools or something else, I think we'd have better
results if those of us with a keen interest in a particular subsystem could
see the individual changes and really grasp what is changing, and why.
Bill Rugolsky
rugolsky@ead.dsa.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/