This is a "think piece" :-)
This is abridged from this week's Linux Weekly News (http://lwn.net). Do
we need something like this? Having three patches waiting for review and
another three for super-review, how can we lower the barrier to entry for
contribution while maintaining code quality?
Can we remove the sr= restriction for all whitespace and comment-only
changes? Can we give people checkin rights on the understanding that they
only check in such changes? Polish is getting more and more important as
we approach 1.0, and the core developers just don't have time.
Ideas welcomed...
"The last few months have seen a flurry of activity from a group of
developers known, informally, as "kernel janitors." As suggested by their
name, the janitors make it their job to clean up messes in the kernel code
base. Recent contributions include fixing a mass of erroneous user space
pointer dereferences, straightening out inconsistent treatment of kernel
locks, and even hundreds of spelling fixes.
This project raises an interesting question. The need for janitorial work
is reasonably clear. Any large body of code is going to have its dark,
dusty areas in need of a serious sweeping, and the kernel is a larger and
more complex body than many. And the janitors have noted an important
point: an error pattern that is found in one section of code has a high
likelihood of recurring in other places. Once a particular type of mistake
has been found, it makes great sense to go looking for instances of the
same mistake elsewhere. This is essentially the same approach as that used
by the OpenBSD team to root out security problems before they are
exploited.
In fact, janitorial work can be a good entry path for aspiring kernel
hackers. Performing major surgery on the kernel and getting the changes
past the gatekeepers can be an intimidating prospect; small and obvious
bug fixes are a much easier start. And they can lead to bigger things:
The organization of the janitors can be seen as another sign of "growing
up" in the Linux community. As the kernel grows and evolves, organizations
develop around it to keep things clean and ensure the quality and
stability of the code base. At some point, the kernel may even have an
organized patch management scheme, regression tests, and other tools that
many development projects have taken for granted for some time.
The kernel, meanwhile, is far from the only large development project in
the free software community. No doubt, many other projects should look at
the kernel janitors organization and consider setting up something
similar. The benefits, in terms of improved code and a better supply of
new hackers, could be both large and
immediate."
