Some thinking, for one thing.
One "patch penguin" scales no better than I do. In fact, I will claim
that most of them scale a whole lot worse.
The fact is, we've had "patch penguins" pretty much forever, and they
are called subsystem maintainers. They maintain their own subsystem, ie
people like David Miller (networking), Kai Germaschewski (ISDN), Greg KH
(USB), Ben Collins (firewire), Al Viro (VFS), Andrew Morton (ext3), Ingo
Molnar (scheduler), Jeff Garzik (network drivers) etc etc.
If there are problems with certain patches, it tends to be due to one or
more of:
- the subsystem is badly modularized (quite common, originally. I don't
think many people realize how _far_ Linux has come in the last five
years wrt issues like architectures, driver independence, filesystem
infrastructure etc). And it still happens.
- lack of maintainer interest. Many "maintainers" are less interested
in true merging than in trying to just push whatever code they have,
and only ever grow their patches instead of keeping them in pieces.
This is usually a matter of getting used to it, and the best people
get used to it really quickly (Andrea, for example, used to not do
this well at all, but look at how he does it now! From a merge
standpoint, his patches have gone from "horrible" to "very good")
- personality/communication issues. Yes, they happen. I've tried to
have other people be "filters" for the people I cannot work with, but
I have to say that most of the time when I can't work with somebody,
others have real problems with those people too.
(An example of a very successful situation: David Miller and Alexey
Kuznetsov: Alexey used to have these rather uncontrolled patches that
I couldn't judge or work with but that obviously had a lot of
potential, and David acting as a filter made them a very successful
team.)
In short, if you have areas or patches that you feel have had problems,
ask yourself _why_ those areas have problems.
A word of warning: good maintainers are hard to find. Getting more of
them helps, but at some point it can actually be more useful to help the
_existing_ ones. I've got about ten-twenty people I really trust, and
quite frankly, the way people work is hardcoded in our DNA. Nobody
"really trusts" hundreds of people. The way to make these things scale
out more is to increase the network of trust not by trying to push it on
me, but by making it more of a _network_, not a star-topology around me.
In short: don't try to come up with a "patch penguin". Instead try to
help existing maintainers, or maybe help grow new ones. THAT is the way
to scalability.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/