On Tuesday 29 January 2002 01:00 am, Linus Torvalds wrote:> On Mon, 28 Jan 2002, Rob Landley wrote:> > > 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.)>> No, I don't really think an "integration manager" works well.

So what was Alan Cox doing all those years? What is Dave Jones currently doing?

> I think it helps a lot to have people pick up patches that nobody else> wants to maintain, and to gather them up. Andrea does that to some degree.

It's not a question of patches people don't want to maintain, it's a question of patches getting much wider testing and better feedback when they're in a larger tree, and the maintainers of the various patches getting better warning about other patches that break them or that they break other patches.

When two developers share a common tree, they notice when they break each other's stuff, and they resolve it. When two developers go off in isolation, they break each other's stuff as a matter of course. And testers who have to hunt down a patch are are willing to apply it generally aren't the ones who raise an objection once it gets applied to the next tree they download.

> But it is _much_ better if you have somebody who is a point-man for> specific areas.

I'm not proposing replacing the current subsystem maintainers. But are the current subsystem maintainers happy?

I thought they weren't, but I guess that by their silence, they must be thrilled, so... (Sorry, I seem to be getting a lot more support in private than anybody is willing to cc: to the list. I'm new at this politics business...)

> The problem with an overall guy is that there can't be too many of them.> The very thing you are _complaining_ about is in fact that there are a> number of over-all guys without clear focus, which only leads to confusion> about who handles what.>> Clarity is good.

The fact Jens Axboe handles one system, Stephen C. Tweedie another, Andre Hedrick a third, Rik van Riel a fourth, and Eric Raymond a fifth, is not particularly confusing. It's when the integration and debugging of Jens' patches in 2.5 blocks the inclusion of basically anything else for a month or two, and then Andre Hedrick has to mount a publicity campaign on linux-kernel to get any attention paid to his patches, and Eric's help patches get ignored for 33 consecutive releases.

Rik was replaced by Andrea as the VM maintainer, and Rik has publicly stated that he thinks you were dropping his VM patches for months at a time, while he was the maintainer and the VM was a subsystem definitely in need of patches. Are you saying that the system was working well? Are you saying that it was a one-time thing that is now resolved and won't recur?

Okay, maybe a lot of this is all miscommunication. But that just identifies the TYPE of the problem, doesn't it?

> > 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?>> No, I'm saying that there are not very many peopel who can do it, and who> can get the kind of trust that they are _everywhere_. Let's face it, Alan> grew to be respected because he did lots of different stuff over many> years, and he proved himself more than capable. And I suspect he's _quite_> happy not being in the middle of it right now.. It's a tough job.

It is a tough job, and I understand that not everybody can be a good maintainer. But currently at least Alan, Dave Jones, and Andrea are all maintaining their own public trees, from which they break out patches to send on to an "official" Linux tree. (As for Alan not being "in the middle of it", he IS doing his tree again. He's just doing it for 2.4. He's basically being Marcelo's integration lieutenant. Whatever he's burned out on, it's apparently not the job of maintaining a tree. And he's doing it for Marcelo, whose architect role is largely rejecting as much as he possibly can since 2.4 is not a development branch...)

You currently HAVE a de facto integration lieutenant, or else I totally misunderstand what Dave Jones is doing. This is not a position for which applicants currently need to be interviewed, is it? (Do you have a complaint with the job Dave is doing?)

> It's a lot more likely to find people who can maintain _parts_. And if> there are patches that fall out of those parts, that tends to indicate a> lack of modularity, and perhaps a lack of maintainer for those parts.

Sure. But how do the maintainers piece together their code, resolve the obvious conflicts, and get the new stuff tested by live users in the field who want to live dangerously? They USED to feed stuff into the -ac tree, months if not YEARS before you accepted (or rejected) it. That's not my opinion or my recommendation, that's history. I'm simply proposing that people consider the fact it might be an important and natural part of the process. (When Alan stopped doing it, somebody else basically got shanghaied into doing it.)

> And more likely, even if you _do_ find ten people who can do everything,> you don't want them to.

No, you want one guy with final responsibility for maintaining any tree. Committees produce mostly compromises and deadlocks. That's why I proposed one guy for this job. As I said, the CVS thing was a confusing side issue. (An easier way for the maintainers to do lower-friction merges with the integration maintainer, who would by the CVS administrator and would still have final say over what goes into his tree.)

But the -ac tree did not serve the same purpose as your tree did, and I was under the strong impression that the -ac tree DID serve a purpose. (And, for Marcelo, is starting to do so again.)

There is currently no tree for provisionally integrating code. Or for taking the flood of new driver patches that Alan Cox always fielded. Not code from left field, but code like keith owens' new kbuild, CML2, or rik van riel's reverse mapping patches. Things which have a strong possiblity of being integrated (two of the above you okayed at the kernel summit, one you've expressed interest in), and are ready for wider testing.