In all this discussion, I see a couple of underlying problems. The first
is what is the definition of stability. To many (mostly kernel developers)
the definition of stability "S" depends on number of bug reports "B":
S(infinite) = B(0)
S(X) > S(Y) iff B(X) < B(Y)
The problem is that the kernel community never sees many problems (filtered
through distro's), and the severity and importance of problem reports
is confused. Bug tracking could help, but it would have to be universal
and painless; bugzilla doesn't cut it.
But many end-user's and IT types seem to feel that the definition
of stability is based on rate of change, ie patches (P) over time.
S(X) > S(Y) iff P(X)/t > P(Y)/t
These are the people who can't believe 2.6 is stable because they see so
much change. Having 2.6.x.y may make this group happy, but probably only
after such a long period that the the mainline kernel is 6 months ahead.
The whole point of the continuous 2.6 process, was to avoid having the
multiple tree backporting mess that 2.5/2.4 had, especially the distro kernels
were all some hodge-podge of 2.5 and 2.4 stuff. Fixing the same bug on multiple
branches is a fundamentally flawed process that is sure to allow some bug fixes
to be missed.
The third group are those that install release 2.6.X and have some problem;
nobody wants to believe their problem is unique. So often, the user says makes
the fallacious argument that "if I had a problem, then all users will have the
problem, therefore it is unstable." These people will never be happy, they can
stay on 2.2.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
