lkml.org 
[lkml]   [1997]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject"2.0.31", etc. -- ENOUGH, please!
Date
Folks, could we PLEASE put the "2.0.31, please," "Take a Deep Breath," and
other related threads to rest and get on with kernel development and
discussion??? Except for restating a few key points, I'm not sure these
threads are serving any real purpose anymore, except to frustrate
valuable, hard-working developers like Linus, David Miller, Alan Cox, Ted
Ts'o, and others.

Could we all please agree on a few points, which've been true throughout at
least the past couple of years, if not the entire Linux history:

1. Odd-numbered kernels, like 1.1.x, 1.3.x, 2.1.x, etc. are development
kernels and do not come with any warranty or guarantee, may cause cancer
in lab rats, may affect the ozone layer, may fuel conspiracy theories,
etc.

2. Because of the millions of possible combinations of motherboards,
BIOSes, controllers, etc. there's no way to offer a 100 percent guarantee
that every kernel, whether it be production or development, will compile
in a given environment.

3. You should ALWAYS be careful when installing a new kernel, whether it be
a production or development Linux kernel, or a new Solaris, HP, etc.
kernel, or a new MS Windows or MacOS version. Test-drive the new beast
in a non-critical environment, and keep a copy of the last stable kernel
around. If the test works fine, then deploy. If it doesn't, then back
up to the previous good kernel. (The same rings true for all software,
not just kernels.)

4. If you find a compilation error or a runtime bug with the kernel, try to
gather as much information as possible and report it in a polite manner.
The Linux community has come as far as it has because of cooperation and
civility, not confrontation and hostility.

5. If you feel you can make a contribution to the development,
maintenance, documentation, testing, etc. of the kernel, then please
do, but PLEASE respect the work and wishes of the maintainers.

Yelling at or destructively criticizing the kernel developers for kernel
design, bugs, testing problems, documentation problems, etc. won't help; I
quit my last job because management did just that, and, well, the
ramifications were fairly significant, especially when colleagues followed
me. I'd hate to see Linus, David, Alan, Ted, or others give up for
similar reasons. Help out where you can, but if you don't have the time,
skill, or resource, then be patient and make do with what you have. If
that's not feasible, then look at some of the Linux competitors, but be
ready to pay thousands of dollars to have any problems taken seriously.

Just my opinion -- I could certainly be wrong. If you feel I am, please
respond to me privately, and let's let the list get back to fixing bugs,
adding new features, etc.

--------------------------------------
Christopher A. Smith
Arlington VA * casmith@clark.net

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.045 / U:1.884 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site