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/