Messages in this thread | | | Date | Wed, 9 Aug 2000 10:58:34 -0400 | From | Matthew Wilcox <> | Subject | Re: 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/
| |