> One thing intrigued me in this thread - which was not the discussion
> itself, but the fact that Rik is using bitkeeper.
>
> How many other people are actually using bitkeeper already for the kernel?
> I know the ppc guys have, for a long time, but who else is? bk, unlike
> CVS, should at least be _able_ to handle a "network of people" kind of
> approach.
One thing that's intrigued ME is the explanation of the hierarchy of
maintainers. There ARE specific people that patches should be reviewed by
before being sent to you, there even seems to be a directed graph of them.
It would be kind of nice if it was documented enough that at least the
maintainers in the maintainers list knew what it was, and who they should
forward stuff on to after reviewing it. That might go a ways towards
addressing the "hitting resend isn't working" problem...
You've said that the tier under you (who you DO semi-reliably accept patches
from) is a group of ten to twenty people. If we knew who those people were,
we could bug them to name THEIR secretary lists (or figure it out from the
maintainers list)...
In your original response to the patch penguin proposal, you mentioned:
>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.
You also said:
> The VM stuff right now seems to be Andrea, Dave or you yourself.
That was responding to Rik van Riel, I'm guessing "Dave" is Dave Jones(?),
and of course Andrea would be Andrea Arcangeli. It seems that Andrea
Arcangeli is the default VM maintainer, and that Dave Jones is gradually
getting sucked into Alan Cox's old position as "miscelaneous maintainer"
putting out a "this needs wider testing" tree.
The above seems to be about the full list I can assemble from recent emails.
(You've also used David Miller again as an example in a later email, you put
Paul Mackerras as a subordinate maintainer under him, and "Greg"
(Kroah-Hartmann) had Johannes Erdfelt under him handling UHCI. This isn't
really new information about the top ten, more like some examples to help in
tree building under them.)
This is eleven "top level" maintainers, one of whom is handling ext3 which
sounds kind of odd... (If David Miller is networking and Jeff Garzik is
network drivers, would there be a "filesystem drivers" guy paired off with Al
Viro? Does EXT2 go through Andrew Morton as well? Would Hans Reiser submit
directly to you for ReiserFS patches, or should he get a signoff from...
Um... Andrew? Al? Try to get it into the -dj tree first? Could I have a
hint?)
To clarify what I'm aiming at: Are these eleven people a significant portion
of the group of people who, if code makes it as far as them and they sign off
on it, you'd then be willing to at least review it and if necessary
explicitly reject? [1] Should some of them be forwarding their patches to
somebody other than you? Are there more people on the list that lower level
maintainers should be funneling patches to in order to eventually get them
into your tree?
A two tier maintainer system definitely sounds like an improvement if that
will help the process scale. It's just that today is the first I've heard
about it, and I had TRIED to study the situation before opening my big
mouth...
> Linus
Rob
[Footnote 1] Implicit rejections can be REALLY stressful when combined with
delaying the of inclusion of code that isn't actually rejected, but just not
convenient to include right now. It means that code that isn't merged
immediately soon starts to smell of failure. The throught process seems to
go "If Linus hasn't accepted it, and Linus ignores patches he's rejecting,
maybe he's rejecting this. If so, the reason is something we need to figure
out on our own, so let's all pile on the code and start badmouthing it until
we figure out why Linus doesn't like it." This can easily go beyond useful
code review into pointless flame wars. Arranging a system where it's
possible to have some kind of progress indicator (even a "distance from
Linus" index as patches progress through the maintainer tree) seems like a
good thing to me...
-
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/