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.
> 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/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:00:57 EST