Sure. But Alan doesn't, and Dave Jones (with enough experience) shouldn't.
You have architecture duties. You're worried about the future of the code.
You have to understand just about everybody's subsystem, so you can veto a
patch from somebody like Jens Axboe or Andre Hedrick if you have an objection
to it.
An integration maintainer would NOT be making any major architectural
decisions, they would be integrating the code from the maintainers,
collecting the patches for the unmaintained areas of code, and resolving
issues between maintainers that are purely implementation details.
Then you code review what they do anyway as the architect, saying whether or
not it's a good idea. But you don't have to deal with the obvious grunt work
that's largely a matter of figuring out which bits don't compile because
person A was not talking to person B.
> 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.
I'm suggesting an integration maintainer, whose explicit job is to put
together patches from the various subsystem maintainers, and only directly
accept patches for areas of code that do not HAVE any other subsystem
maintainer.
Alan Cox used to do this (and is starting to do it again for Marcelo in 2.4).
Dave Jones is currently the guy doing this for you, taking patches, sorting
through them, and then feeding them on to you.
> 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.
Yup. Architecture issue. Still your problem, I'm fraid.
> - 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.
Patch penguin's job. Foist this grunt work off on him.
> 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")
And needed patches from people who aren't very good have to wait years for
the developer to learn how to feed you the right kind of patches?
If the patch is for a specific subsystem, then obviously your first line of
defense fighting off sturgeon's law is the subsystem maintainer. But you
don't seem to have been taking patches even from subsystem maintainers in a
timely manner, and how can people tell the difference between you dropping a
patch because you have an objection to it and you dropping a patch because
your mailbox overfloweth? (You keep complaining people never send you
patches. People are suggesting automated patch remailers to spam your
mailbox even harder. There has GOT to be a better way...)
> - 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.
Query: Do you not believe you have been dropping a significant number of good
patches on the floor?
> 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.
You don't see an integration maintainer as a step in the right direction?
(It's not a star topology, it's a tree.)
Having lots of dispirate overlapping trees fragments development, fragments
the testers, and makes an awful lot more WORK for everybody involved.
> 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.
Are you saying that Alan Cox's didn't serve a purpose during the 2.2 kernel
time frame, and that Dave Jones is currently wasting his time?
I'm confused here: "don't try to come up with a patch penguin", "help
existing maintainers" (that's the patch penguin's job) "help grow new
[maintainers]"... The patch penguin IS an integration maintainer. That's
what I'm talking about. (Patch penguin, patch pumpkin. Patch pumkin, patch
penguin. I can say "integration maintainer" if it would help...)
I missed a curve somewhere. Maybe the original message wasn't clear? I am
suggesting making Dave Jones the integration maintainer (a position he
currently unofficially holds, and which Alan Cox did before him), and simply
telling everybody who's complaining that their patches are getting silently
dropped or ignored to try getting them into HIS tree first before bothering
you about it.
I'm not asking for a major change here, I'm talking about clarifying the
current ad-hoc development process. Formalizing an existing de facto
position so people farther out in the development process know what to do and
where to go.
> Linus
Rob
-
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/