On Fri, 26 Jul 1996, Kernel Mailing List wrote (among other things):
> So can we get this straight, are kernels with even second clause revision
> numbers going to be stable or what, we should not go back to those days of
> kernel releases every day for a supposedly stable kernel!
I agree, and IMHO it stands for credibility. You never hear any
Micro-something Loose-those user answered by the tech support: Get the
next version, it's MORE stable. This is why many ISPs still stick to
good-old 1.2.13. And since we all agree that Linux should be an
alternative to the Micro-something environments, I personally would like to
see the thing getting systematic and stable.
I'm a lurker on this list (usually), and I have the idea that the numbers
were consistent in the "odd minor numbers unstable" scheme UNTIL 1.3.99,
after which, instead of going to 1.3.100 or 1.5.1 or whatever, there had
been 2.0-pre-1 release.
So at that point, people were eager for a stable "over 3" kernel version.
Linus was at some kinds of pressure, There was a deadline which he set but
didn't meet, etc. This has been (IMO) the source for this "2-pre" idea, as
well as the current 2.0.* scheme, which is inconsistent.
Again, speaking from my own observations and feelings, I think that the
following conclusions should be derived, and applied to the future:
A. Don't wait to x.x.85 for the code freeze. This will produce more stable
kernels, with less added features. Keyword is stable. What users see
when they look at recent kernels is titled "Development".
B. Don't set deadlines that can't be met. This implies to not set
deadlines at all :-) but at least try.
C. Don't give in to pressure. It has proven to give a lesser "product".
And the constructive part:
D. Announce the 2.0.x kernels to be development, and a special case in the
kernel numbering system. Re-announce the numbering system - a.b.c where
a is major, b is minor (and odd numbers means development), and c is a
serial number. And in no way should numbers like 95 be excluded. Linux
is also a competition to OS/2 (tm), would you throw away version 2?
E. Skip 2.1.x altogether, or rather move there NOW at once, while
still adopting step A.
F. Start 2.2.x tree in parallel, which should contain VERY STABLE COPIES
of the development kernel. Stable means PRODUCTION kernels, kernels
that could stand a load average of 10, with 100 rampaging users, for
300 days straight, when the 10 minutes down time is due to a power
failure or fire in the building. Remove from the 2.2 kernel
configuration ANY option whatsoever which is still known to cause
trouble. The user is KNOWINGLY going to get the development version if
he/she wants that feature.
I think there is a great deal of importance to increasing Linux'
credibility in the eyes of the users. I am trying to introduce Linux
systems into the CS faculty in the Technion, and I am facing great
difficulty because of things like:
"We're trying to stay away from things like that. They don't have support.
They are not reliable".
People _STILL_ have the impression that Linux is some student project in
some OS lab in Finland (no offense, Linus) and I think that this
impression is a great boulder in Linux' way to excellence.
Thus ends the $0.02 worth of mine. I hope this will stir things up, so if
your reply contains foul language, mail it directly to me and not the
list. If you have complaints about my spelling, please send the correction
as well (unified diffs only).
--------------------------------------------- ....- --.. ----. -.. --. .
Arik Baratz, Regularus Studentus, iNTP, 4Z9DGE
---------------------------------------------------------------------------
http://ccarik.technion.ac.il/~arikb
finger arikb@aluf.technion.ac.il for PGP key.