Re: [linux-tr] Token Ring Bug (This is good :-)).

[Paul Norton <pnorton@ccnusa.com>]

Michael R. Eckhoff writes:
 > 
 > And all this brings up something I've been curious about.
 > 
 > If someone were to think the driver was total shit, write a new one, and submit
 > it for inclusion into the kernel, what keeps them from doing it and knocking
 > this driver out of the tree?  

Absolutely nothing.  It's Darwinism, plain and simple.  If it's a
better driver it _should_ replace the existing one. 

 > Or what keeps them from writing a patch, such as for the source routing, which
 > might cause more problems with the kernel than it fixes on the network?
 > 
 > Is this a problem with the open source model of Linux?  I know you should
 > always check the maintainers file and contact those people if you have
 > modifications or changes, but what if you don't?

I see what you're getting at.  Basically, what's to prevent bad code 
from making it into the kernel?   In theory somebody writes a patch,
tests the patch, and submits it to the maintainer of the code being
patched.  The maintainer evaluates the patch - does it fix what it's
supposed to fix?  does it break anything else?  does it fit in with
the development strategy?  are coding standards met? - tests it, may 
submit it for wider testing, and then either accepts or denies it.
In theory.  In reality that's not always the way it works.  Often
patches simply posted to linux-kernel get included.  Which is ok if
we're working with development kernels, since nobody expects
development kernels to be 100% stable.  There are plenty of instances
where a patch that appeared in one development kernel got yanked in
the next.  Also, a two line patch has a better chance of making into
the kernel that way than one that changes a lot of code.

The key here is peer review of the code.  Either way the code gets
reviewed.  I suppose that if a patch made it into the kernel that 
the maintainer felt shouldn't have,  he could ask Alan or Linus to
pull it.  But then he would have to justify that request and it
certainly could be refused. 

It used to be that I would scan every kernel for changes to the code I 
maintained.  These days I'm not that assiduous, and spend my dwindling
free time either writing new code, debugging, or reviewing other
people's patches to the code.  And, frankly, since the start of the
year I've had precious little time to do even that.  Fortunately the
semester is almost over. 

Paul