I understand why he doesn't do that: he can't function if the code is
changing under him in ways that suprise him. (Especially he can't function
as architect without doing code inspection.)
Linus DOES apply larger patches from maintainers with less scrutiny, but
there still IS scrutiny of each patch. (At the very least, checking which
files it touches.)
> Each subsystem maintainer should handle patches to that subsystem, and
> you should remove your own patch permissions for only those subsystems.
> You could get involved with only changes in direction that affect more
> than one subsystem.
Linus also reserves the right to mess with a maintainer's code and force a
patch back down the tree for them to resync with. He just did it with the
help files (after a "private flamewar"). In this case, the maintainer was
caught by suprise, claiming to be unaware that Linus expected him to make
that change, which just seems to be one more example of a lack of
communication between Linus and a maintainer. This time, instead of Linus
not getting the maintainer's message (patch), the maintainer doesn't get
linus's message ("Go do this, in this order".) So we've got examples of
messages getting dropped in both directions, making the maintainer look
inattentive when he claims otherwise, and making Linus look inattentive when
HE claims otherwise...
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/