James Bottomley started off this session by saying that he had proposed it
after being annoyed by one too many white space patches in his mailbox. He
does not believe that encouraging people to blindly fix white space problems
is a good way to bring in new developers. So the central question for this
session was: how can we do a better job of involving newcomers in the
kernel development process?
Linus asked that new developers not start by trying to fix warnings - a
task which currently appears on the "to do" list run by
the janitors project. In the past, he has not enjoyed that experience at
all. Beginner fixes for warnings tend to be aimed at silencing the warning
rather than really understanding what is going on; as a result, they often break
things. A better place for people to start, he says, is by testing the kernel and
providing good bug reports.
Andi Kleen said that task lists can be useful. He put together a document
on how to switch code over to the unlocked_ioctl() file operation,
thus eliminating the big kernel lock. Some people made use of it and got
some useful work done. Linus pointed out, though, that a certain Alan Cox
followed that document and got things wrong, forcing the developers to
revert his broken patch.
Matthew Wilcox stated that the problem in the kernel community is not a
shortage of patches - it's a shortage of review. So he would rather start
new developers on tasks like bug reports. Jeff Garzik noted that good
results can be had by encouraging new developers to acquire an obscure
piece of hardware and improve the driver. That only works if one is
willing to put in a fair amount of mentoring time, though.
Mentoring is a subject that came around a few times. Greg Kroah-Hartman's
Linux driver project work has provided a forum for mentoring, and that has
helped a number of developers to improve their skills. But Dave Airlie
asked how many developers had been "mentored" into the system; almost no
hands were raised. The thing that creates new kernel developers still
appears to be bugs that irritate people into fixing them. That led to the
inevitable suggestion that the developers in the room should fix fewer
bugs, providing more opportunities for the recruiting of new developers.
Having prospective developers run regression tests was suggested, but was
not received with a great deal of enthusiasm. Far better, said Linus, was
to have people test out as much hardware as they can; that's where the real
One often-cited problem with the janitors project is that it is not good at
graduating developers to bigger and better tasks. Any sort of mentoring
effort should be oriented toward helping developers to grow while, at the
same time, having them do something useful at every step.
Andrew Morton - who was quieter than usual this year - noted that quite a
few people who express interest in kernel development disappear before too
long. Putting effort into mentoring them can thus lead to a lot of wasted
time. It is better, he said, to do this kind of mentoring in a group
situation. There have been problems, though, with people posting incorrect
answers to questions on mailing lists, so group mentoring must be handled
carefully as well.
Andrew repeated his statement that the best thing for new developers to do
is to ensure that every system they have access to runs perfectly with
An attempt was made to get some action items out of the session. The
creation of a mentoring project was suggested, but nobody stepped forward
to take that on. There was a request for more distributors to package
testing kernels for users who would like to experiment with the leading
edge. Al Viro, though, argued for a stronger emphasis on getting people to
read code, rather than write it. That reading can take the form of code
review or simply taking the time to figure things out.
Linus would like a tool which could create a minimally useful kernel
configuration for a given system. A full distributor configuration takes
far too long to build, and the prospect of creating a custom configuration
is increasingly daunting. Linus noted that his first kernel for a new
system never works - he is certainly not unique in that regard. It turns
out that such a tool exists; it will be dusted off and posted soon.
to post comments)