No Linus you don't need any *help* with drivers you really just need
to *delegate* the whole thing. The only thing you should maybe check
even in a 1MB diff from Donald for example is whatever it's leaving:
diff -urN linux/drivers/net
Even if the 1MB does cause intermittent problems.
But if you continue to act like a last ultimative instance for
*everything* then don't wonder that some people start to get
distracted...
> 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.
But Alan's patches are usually involved in the "kernel" of the "kernel".
Or maybe more precisely: the generic parts of it. Drivers are a much
much
different matter.
Don't wonder a firm self assured and competent person doesn't feel
oblidget for the slavish work of the splitting (which is indeed
plenty of), where it's really not neccesary at all for any technical
reason other then maybe someones need for total controll.
I remember the discussion about the tulip where you where arguing
over and over again in fact against the competence of Donald. Why didn't
you
just let the updated version go in? Even with obvious bug's you did know
about!
And then let Donald just see himself? Was it too difficult to
prepare for diff -R in case of a total disaster and just forwarding
all the bug reports to him in
the time between or what? No wonder he doesn't like to expose
himself to this very often. Some goes for the arguments in the
discussion against Mark Lord.
Those are the real reaons for the problems with the isdn, ftape,
bttv, and many in fact separately maintained driver groups.
> 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).
Hell then what's the MAINTAINER's file supposed to be?
--Marcin
-
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/