Messages in this thread | | | Date | Thu, 29 May 2008 17:06:15 +0200 (CEST) | From | Jiri Kosina <> | Subject | Re: [Ksummit-2008-discuss] Fixing the Kernel Janitors project |
| |
On Thu, 29 May 2008, James Bottomley wrote:
> Really, I think that's what our mistake is in the recruitment program > is: we need to start people out on useful tasks that they can do rather > than on tasks we find annoying and useless in the hope they move on to > something better.
I fully agree, but my impression is that this really is not going to be easy. Fixing bugs definitely is a good way to start kernel coding -- it forces you to understand the internals of the source, get used to the coding style by reading the code, etc. Unfortunately, it's simply not very attractive for newcomers.
For example -- I am leading a seminar at university, oriented at linux kernel internals. I provide the possibility to students either to
- write some stand-alone interesting kernel project - fix a few non-trivial bugs in kernel bugzilla - chose any part of a kernel, learn how it works, and present this to other seminar attendees
The feedback I often get from students (and these guys are studying computer science) is
- writing some wholy new interesting kernel project is usually too complicated (both coming with an interesting idea for a project, and doing the coding itself) - fixing random bugs from kernel bugzilla is boring (spending 10 hours looking for missing '=' doesn't really attract them)
So in overwhelming majority of cases, they just chose the presentation.
All I want to say is that I could very well imagine that a lot of newcomers will find "hey, feel free to crawl through bugzilla and fix whatever you are able to fix" very non-attractive. Not that I have any better idea right now, though.
-- Jiri Kosina SUSE Labs
| |