> Exactly my point. Your comment that "Now that companies are beginning
> to run Linux on production systems, the carefree attitude toward "stable"
> kernels has to change." is what I was commenting on. That represents the idea
> that because some special group of people are using Linux that we must limit
> Linux in some way, such as upgrading very needed parts of the kernel.
I phrased that poorly. Thanks for bringing it to my attention so I can try
again. Linux has been evolving from an OS suitable for hobbyists to one of
the most stable production-quality OSes available. I'm just pointing out
what I see as an obstacle looming on this evolutionary path.
> Think of those of us who have to upgrade to a new kernel, then
> discover that the patches we have to apply (ie: RAID patches) won't apply
> cleanly! This is NOT good. I've had to go through a couple of times and
> apply the raid patch by hand, and I've been bitten by doing that once or
> twice, badly.
I agree that having to deal with old patches is bad, but it is a known
risk in using non-standard patches, even if they are widely used. Because
the RAID code changed in a way that was not backwards-compatible, a choice
must be made between breaking a standard kernel feature in a stable kernel
and leaving people using the currently non-standard (from a kernel
perspective) feature with the hassle of patch incompatibilities. Both
options are bad. Getting a stable 2.4 out with the new RAID code solves
both problems.
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.
> I would agree that perhaps it should be put in as a seperate CONFIG
> option, and even marked 'experimental' if people are truely concerned,
> but it needs to get updated with the regular kernel releases.
I think this is a good suggestion, though I'd rather see the effort go
into getting these features into 2.3, getting 2.3 frozen, then
stabilized, and released as 2.4.
M Carling
-
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/