I have received a number of emails from my blog readers asking me for the procedures to be followed in order to join the kernel development process. It is not a hard process at all. But I thought of explaining the entire ‘tree of development’ so that new developers will have a clear picture regarding the process.

Where to start?

In order to become a good contributor of kernel patches, you must have a strong background in C. If you have expertise in C++, it will be an addon (especially if you want to stick yourself to device drivers).

If you are good in this field, then I recommend you to signup for the Linux Kernel mailing list (LKML). You can do that by sending an email to ‘majordomo@vger.kernel.org’ with ‘subscribe linux-kernel’ as the body text. You need to note that this is a very high traffic (in terms of volume) list (I used to receive about 250 emails per day). So, it is highly recommended that you store these emails in a separate  folder in your email client (if you are using a POP3 supported email) or you set a custom filter (if you are using Gmail).

You can watch how people are reporting bugs and fixes in this mailing list.

Development

Linux kernel development is one of the largest and fastest growing projects in the world. Since it is open source, all the development works are transparent. The picture shown below explains the entire process in a nutshell.

There are 4 levels in this hierarchical tree structure. Assume that you are the maintainer of a driver (say, if you have developed it), then all the developer will report to you when they stumble upon a bug. Similarly, they may also report fixes for these bugs. Now you can accept these fixes by ‘signing off’ on it (we will discuss about this step later).

Once they have done that the fix (patch) will be send to the subsystem maintainer (who maintains a large set of drivers or core files). And they will also check if the new fix is good. If they like it, they will also ‘sign off’ on the file and will be send to Linus or Andrew (top developers).

Kernel Releases

Earlier we used to have odd numbers to represent development release and even for stable releases. But we are no longer following this. Once the patches have been accepted, Linus will release an ‘RC’ (release candidate) version. Now, some of the subsystem maintainers who have not send the patches may send them to Linus. And then, he will release the RC2.

The next RC releases are for bug fixes and regressions. During this stage, many developers will test the new version and will report all the bugs. For your reference, here is the data released by the Linux Foundation regarding 2.6.25 release.

January 24 : 2.6.24 stable release

February 10: 2.6.25-rc1, merge window closes

February 15: 2.6.25-rc2

February 24 : 2.6.25-rc3

March 4 : 2.6.25-rc4

March 9 : 2.6.25-rc5

March 16 : 2.6.25-rc6

March 25: 2.6.25-rc7

April 1:2.6.25-rc8

April 11: 2.6.25-rc9

April 16 : 2.6.25 stable release

How fact is the change?

There are about 2400 developers in this community. Many of these developers are employed by commercial companies (like IBM, Redhat, Novell, Google and many others). And you can see there are 9.2 million lines of code in Linux kernel (but this may not be there in the one provided by your distribution, as about 55% of this code deals will drivers and you don’t need all these drivers).

This means Linux is the best operating system. And it is also the one which supports the largest number of devices. Every year 10% new code is added to the kernel and they release a new kernel in every 2.75 months.

Here is data from Linux foundation:

2.6.26 : July 13, 2008

2.6.25 : April 16, 2008

2.6.24 : January 24, 2008

2.6.23 : October 9, 2007

2.6.22 : July 8, 2007

2.6.21 : April 25, 2007

2.6.20 : February 7, 2007

Another thing that you have noticed is that when major distros like Fedora (by Redhat) or OpenSuse (by Novell) are released those kernel versions hang around for a greater time. This is because most of the active developers come from these places and they want that version to stay longer.

You may noticed that in the picture shown above positions 1 and 5 are not shown. Well, the first place goes to “Amateurs” and the 5th place goes to “Anonymous Individuals” (thanks to Greg Hartman for this information). Since they don’t fit into the category , they are not shown.

Signed-off-by

The revision control software (for source code management) used by the Linux development community is GIT, which was developed by Linus Torvalds for Linux kernel development project itself. It allows you to track the revision and allows you to sign off on the file by using the  ‘Signed-off-by’ command.

For your information, here is the statistics (top) regarding the sign off activity (Again thanks to Greg Hartman for the list) :

If you are good C programmer go ahead and start participating in this great project!