Before actively contributing to kernel development, it is important to understand the development cycle adopted by the Linux kernel community. This chapter describes the development process.
The stable series have even point release numbers (e.g. 2.2.x and 2.4.x.), generally minor releases contain bug fixes and small enhancements. Stable releases generally occur less often and most Linux distributions are based around these releases. Some "vintages" of kernel are better than others, the really bad ones are marked with a "-dontuse" filename extension.
Unstable kernels contain less proven code and change more radically between minor releases. They serve as test beds for new drivers, experimental features and innovative algorithms.
Generally, it is a bad idea to run an unstable kernel on a system that matters. Having a dedicated box for testing unstable kernels is recommended!
Linus announces a feature freeze to indicate that he will not be considering any more new features until the release of a new stable kernel. This is usually followed by a flurry of people trying to get patches into the source tree before Linus actually enforces the feature freeze!
The idea is to introduce a period of stability to hunt down and fix the worst of the bugs introduced by all the new features.
Code freezes are similar in concept to feature freezes, but are more restrictive; only fixes for serious bugs are accepted. Code freezes are just one more step towards the release of a new stable kernel.
Between minor releases of both stable and unstable kernels, there are several intermediate releases intended to iteratively test a small number of submissions together. These releases have either -preXX or -YYXX extensions, where XX is the incremental version number and YY are the initials of the maintainer (example: -ac12 indicates the 12th incremental release by Alan Cox).
Now head over to the Linux-Kernel mailing list archives and spend some time looking over the postings of the past month or so. Try and find/follow a couple of threads that look interesting to you, where the maintainers get involved. If you don't know who is who in the community, take a look at the MAINTAINERS file in the top level of the kernel source tree.
By doing this you will:
Now find and try out some experimental patches that look interesting to you and provide feedback to the author. If you think it is appropriate to post back to the list, be sure to read the FAQfirst.