A cut copy past from a mailing list
My advise would be to start by trying to fix some bugs. There are
plenty to go around and fixing bugs is a great way to learn since you
need to understand (and thus learn) the code surrounding the bug in
order to fix it properly, so it usually teaches a lot. Submitting
small bug fixes is also a great way to get comfortable with submitting
Finding bugs to fix is easy;
Build a bunch of ‘randconfig’ kernels and log the output from the
build. Building some 10-20 randconfig kernels usually exposes plenty
of warnings and errors during the build. Fixing some of those should
keep you busy for a while.
Sign up with Coverity (http://www.coverity.com/) to get access to the
results of their regular runs of Coverity Prevent against the kernel
source (). Their static analysis of the kernel source finds many bugs
that need fixing. Lots of good work there that needs doing.
Run the ‘sparse’ tool
(http://www.kernel.org/pub/software/devel/sparse/) against the kernel
source and evaluate the problems it finds. Try and fix any real
problems it reports.
Go through the kernel Bugzilla (http://bugzilla.kernel.org/) and see
if you can fix any of the many bugs filed in it. There’s a metric
butload of bugs filed in there that need attention.
Grep the kernel source for “FIXME”, “XXX” and similar comments. They
often describe areas of the code that has known bugs, could be
optimized, needs review etc. Lots of work to do can be found that way.
Look through the Kernel Janitors TODO list
(http://kernelnewbies.org/KernelJanitors/Todo) for items of interest,
then try to fix some of the issues on the list.
Naturally there’s also other work that can be done, like writing a
driver for some, currently unsupported, hardware etc, but I’d
recommend you get your feet wet with bugfixing first 🙂