KS2008: Fixing the Kernel Janitors Project

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 problems lie.

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 current kernels.

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