Hey, where can we get ahold of these people? :-)
Seriously, I can't imagine maintaining a project like the Linux kernel
with only one man committing to the CVS tree (if any). The way to go
is to have several people committing, but make the CVS tree so
(readonly) accessable that everyone can review old-vs-new a few hours
after the commit. Even the BSD projects with their smaller people base
have enough people to ensure quality that way.
I'm sure the masses of kernel-aware Linux people will be a better
(more scalable) substitute for judgeing over (committed) patches than
a single person can be. The most important thing is probably to look
for special cases the new code will break and that the committer
haven't been aware of. A single person with a wide overview may be
good in this area, but it is not scalable. Also, a patch that was
committed, but backed out after protests may still be of value, since
it:
- Documents that this way doesn't work (and why), better than a
mailing list acrchive can.
- The patch may still be useful for some people and they can find it
in the RCS files.
Personally, I climb up the walls everytime I look at a Linux kernel
patch because I don't have committ messages for the diffs. They're
*so* handy. Ever looked at cvsweb CGI for the FreeBSD src tree? The
usual Linux listing how many lines of code changed in what directory
is just derision. From a kernel source maintaining standpoint (what a
wide range of users can use to work on the code), Linux is in stone
age.
Martin
-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer BSD User Group Hamburg, Germany http://www.bsdhh.org/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/