Cc: Rafael J. Wysocki <rjw@...>, Andrew Morton <akpm@...>, Willy Tarreau <w@...>, David Miller <davem@...>, <linux-kernel@...>, Jiri Slaby <jirislaby@...>
On Thu, May 01, 2008 at 11:23:43AM -0700, Linus Torvalds wrote:
FWIW, the way I'd read that had been "face it, normal folks don't *do*
that and if you hope for more people doing code review - put down your
pipe, it's not even worth talking about". Which managed to get under
my skin, and that's not something that happens often...
Anyway, I'm glad it had been a misparsing; my apologies for the reaction.
The obvious answer: amount of areas where one _can_ do that depends on
some things that can be changed. Namely:
* one needs to understand enough of the area or know where/how
to get the information needed for that. I've got some experience with
the latter and I suspect that most of the folks who do active reviews
have their own set of tricks for getting into the unfamiliar area fast.
Moreover, having such set of tricks is probably _the_ thing that makes
us able to do that kind of work.
Sharing such (i.e. "here's how one wades through unfamiliar
area and gets a sense of what's going on there; here's what one looks
out for; here's how to deal with data structures; here are the signs
of problematic lifetime logics; here's how one formulates hypothesis
about refcounting rules; here's how one verifies such and looks for
possible bugs in that area; etc.) is a Good Idea(tm).
Having the critical areas documented with easy to review in
mind is another thing that would probably help. And yes, it won't
happen overnight, it won't happen for all areas and it won't be mandatory
for maintainers, etc. Previous part (i.e. which questions to ask
about data structures, etc.) would help with that.
FWIW, I'm trying to do that - right now I'm flipping between
wading through Cthulhu-damned fs/locks.c and its friends and getting
the notes I've got from the last month work into edible form (which
includes translation into something that resembles normal English,
among other things - more than half of that is in... well, let's call
it idiom-rich Russian).
* patches should be visible *when* *they* *can* *be* *changed*.
If it's "Linus had pulled from linux-foo.git and that included a merge
from linux-foobar.git, which is developed on foobar-wank@hell.knows.where",
it's too late. It's not just that you don't revert; it's that you _can't_
realistically revert in such situation - not without very massive work.
And I don't know what _can_ be done about that, other than making it
socially discouraged. To some extent it's OK, but my impression is that
some areas are as bad as CVS-based "communities" had been and switch to
git has simply hidden the obvious signs of trouble...
--
