Re: Definitions

[Matthew Wilcox]

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.