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.
I'll admit that I would prefer Donald's process be a little more
transparent, but I would also suggest that having TWO tulip.c v0.91m
versions floating around is just a little obscure, and that's exactly
the situation I was facing with 2.3.18ac8. I wasn't able to locate a
patch on the MAINTAINERS site that moved tulip 0.91m to it's ac8
variant.
I happen to maintain a set of monitoring patches for tulip.c, and so
while others point at Donald's process as broken ("QA disaster" would
suggest this, yes?), I would claim that the existing practice, however
properly motivated, of patches being applied without the maintainer's
acceptance is equally broken.
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.
>
> I'm the one that has to sort out the bug reports of "version 1.23" with "do
> you mean v1.23 of two years ago with five random patches that aren't in my
> CVS tree, or with only four random patches".
>
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.
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.
-Richard
--
Richard Dynes
rdynes@varcom.com
-
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/