>
>
> On Wed, 8 Sep 1999, Bill Rugolsky Jr. wrote:
>
> > I can't speak about RAID, but do you understand that NFS is broken in its
> > unpatched form? HJ's and many of Trond's changes are **bug fixes**.
> > Sure, there are people out there using the NFS included in the kernel,
> > but they are not doing anything serious with it. If they were, they would
> > have seen and complained about RPC problems, attribute caching problems,
> > stale file handles, inode revalidation, locking, ... Some groups, like
> > mine, are locked into an NFS-centric environment: 40 machines, mounting at
> > least four different remote filesystems, with lots of concurrent access.
>
> I understand that the unpatched NFS is broken. All the environments I deal
> with are NFS-centric. The patches are as much of a hassle for me as for
> anyone. I have not argued against bug fixes getting into 2.2.
>
> My main point was that the thread had gone on for a dozen posts without
> anyone specifying whether they were talking about 2.2 or 2.3 and how
> clearly this shows that some developers make little if any distinction
> between the developmental and the "stable" series.
You missed the beginning of the thread, I guess. The reason this thread
came to life was when Alan decided not to include some patches to knfsd &
raid in v2.2.11 (or was it 12?); thus it's pretty clear that we (at least
in the beginning of the thread) was talking of v2.2 kernels.
> > The fact that some userland tool needs to be updated when the kernel is
> > updated seems to me irrelevant....
>
> A kernel that is being updated (aside from bug fixes) is being developed.
> I think calling such a kernel "stable" is unfair to those looking for
> stability.
The problem is, that most people won't use an unstable kernel on
production systems, still they want new drivers to support their hardware.
And it's impossible to keep track of 3 kernel trees; just 2 trees is
almost one too much; some bugfixes takes quite some time to propagate from
one tree to the other.
> > Much more troubling to me
> > is having to ... extract just the bug fixes from the stable patches,
>
> Exactly. Someone who wants stable kernels should not have to extract the
> bug fixes from the developmental updates.
True.
> > If you think Linux is the only system with configuration management
> > problems, just try dealing with Sun's (confusing and frequently broken)
> > patch clusters.
>
> I've been applying Solaris and SunOS patches since 1984. In some ways,
> (official) Linux patches are better than the Solaris patches, but there is
> room for improvement.
Sunsolve... Ouch!
> Everyone seems to agree that the "stable" kernels could and should be more
> stable. I've suggested a methodology for achieving increased stability.
> Several posters don't like my suggestion, but they haven't offered an
> alternative.
The only way to get stable kernels is that more persons test the unstable
kernels in my opinion. The trouble is that the circle of developers that
are most likely to test the kernels have a limited set of hardware, uses a
limited set of software, etc.
/David
_ _
// David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
-
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/