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
--
