Messages in this thread | | | Date | Wed, 20 Oct 1999 10:26:48 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: PATCH 2.3.23 pre 2 compile fixes |
| |
[ re-sent because the original mail had uucp addresses that probably haven't worked in about 15 years ]
On Wed, 20 Oct 1999, Richard Dynes wrote: > > Care to be specific? I know this may incur the wrath of Linus (David > Hinds comes to mind here...), but continuing to ship tulip v0.89H with > the kernel (as of 2.3.21 at least), which doesn't work with shipping > Intel 21143 chips sets, when things like v0.91g and v0.91m are > available seems a little odd.
Nobody has sent me any updates.
I basically never EVER search for patches on the net. If they don't come to me in email, I take that to mean that the author isn't interested in getting them into the standard kernel. The end.
And if the author cannot be bothered to send me timely updates, the author also looks damn silly if he then complains that I don't use his code.
Note the "timely". It's not enough to send me the patch once in a blue moon (Donald doesn't do even that - even though I've asked him face to face, and he always says he will). Again, if the author cannot be bothered to MAINTAIN his patches, it's not worth my time even trying to do it for him: not because I'm a lazy bastard (which I am), but simply because especially with drivers I need help with maintenance, and an old unmaintained driver with known problems is better than a new unmaintained driver with unknown problems.
For example, I do not generally apply large patches. Ask Alan Cox, for example, who does a hell of a good job of maintaining a large portion of the kernel (hats off to Alan), and then ALSO does a hell of a good job in splitting the patches up in their original components.
When I get something like the current "ac" patches from Alan, I don't get just one email with the patch - I _literally_ get about 50 patches that are independent - one per driver, one per subsystem, one per new feature like PCI detection. And then I apply about 48 of them, and explain to him about the two I didn't like and why I didn't apply them.
Most people don't see that kind of code maintenance - they see the full "ac" patch-set, and then some time later they see the patches in my kernel. And sometimes people wonder why the end result isn't the same as the "ac" tree - now you know why. It's either because I decided to not apply a part of it, or (quite often) it's because Alan didn't even send part of it to me, because he knew it had some other issues.
> I hear claims of tulip driver bugs, but rarely any specifics. Part of > that is the nature of drivers, but I'm on both the l-k and l-t lists, > and I specifically filter on tulip, and I don't see lots of bug > reports.
Would you act as an interface between Donald and the standard kernel (ie me and Alan)? Note that it goes both ways - right now Donald doesn't pick up on fixes made by others in the standard kernel, and the same old bug that has been fixed in the standard kernel often shows up in "new" drivers later.
> QED. Now think of the workload on Donald trying to cope with this. I > would find it just a little discouraging. If the kernel at least > shipped with the latest driver from the maintainer, then the rest of > us little people would have a common platform to work from.
Indeed. It would be helpful for Donald as well if he didn't try to maintain tens of patches outside the official kernel tree.
> If tulip (and other drivers) aren't being maintained, then say so. But > AFAIK that isn't the case. Donald's the maintainer. He should be > backed up.
Donald is not the maintainer as far as I am concerned, because I never see any maintenance. He's the AUTHOR, but that is not necessarily the same thing (being the author does mean that he automatically gets the right to be the maintainer if he wants to).
Linus
- 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/
| |