lkml.org 
[lkml]   [2000]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Definitions
On Wed, Aug 09, 2000 at 10:45:13AM -0400, Michael W Zappe wrote:
> Do you get the impression also that getting any real questions addressed
> is a bit difficult? ;-) (Still no response to my original *polite*
> inquiry...) (<-- look Alan, no caps!)

but you still don't seem to be able to press the return key.

> My question still remains: What is a feature, and what is a bug
> fix? And what are the real criteria for making it into the kernel?
> "Technical merit" is not an acceptable answer. On "technical merit"
> Linux makes a horrible can opener. (But I'm sure a salesman could sell
> it as such anyway...)

i very much doubt there are hard and fast rules about this. the informal
heuristics i can see for getting patches into Linus' kernel:

- if it fixes a bug, it probably goes in if it fixes the bug in
an acceptable way and isn't uglier than living with the bug.
- if it does not affect the core code in any way and it's completely
independent, it goes in
- if it's a complete rewrite of a major subsystem, it's early in
a development cycle and Linus likes it, it goes in.
- if it makes the code cleaner, it might go in if Linus thinks it's
safe.

- if it makes the core code uglier, it probably won't go in. (many
patches from commercial companies fall into this category.)
- if it stands a chance of destabilising the whole system late in an alleged
code freeze, it probably won't go in.

--
Revolutions do not require corporate support.

-
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/

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