While the 2.6.23 development cycle has not yet run its course, things are
getting close enough to the end that it makes sense to start looking at the
overall statistics for this release. As of this writing (shortly after
2.6.23-rc6 came out), just over 6,200 non-merge changesets had been added
to the mainline kernel repository. These changesets came from 854
developers - a slightly smaller number than we saw for 2.6.22. Just over
350 of those developers contributed one single changeset.
All told, the patches added almost 430,000 lines, but also removed 406,000
lines, meaning that the kernel grew by just under 23,000 lines - a
relatively small number. That is partially a result of kernel hatcheteer
Adrian Bunk's work: he removed the old SpeedStep code, a number of Open
Sound System drivers, Rise CPU support, and more - a total of almost 73,000
lines removed. Jeff Garzik hacked out over 41,000 lines of network driver
code, and Jens Axboe got rid of over 25,000 lines of code, mostly in the
form of ancient CDROM drivers.
Here is the list of the top contributors to 2.6.23, as counted by
changesets merged and by lines of code changed:
|Most active 2.6.23 developers|
|David S. Miller||107||1.7%|
|H. Peter Anvin||52||0.8%|
|By changed lines|
|David S. Miller||14752||2.2%|
Ingo Molnar comes out on top of the changesets column by virtue of getting
the CFS scheduler merged - then fixing it. Over half of his patches were
accepted after 2.6.23-rc1 came out. Ralf Baechle and Paul Mundt
both contributed many changes to architecture-specific trees, Trond
Myklebust did a lot of NFS work, and, while David Miller had a number of
networking patches, the bulk of his changesets were in the
architecture-specific (SPARC) trees. The figures on the "by changed lines"
side are dominated by code removals (as described above); Jens Axboe also
did a bunch of splice work and merged the "bsg" generic SCSI driver.
Hirokazu Takata did a bunch of m32r architecture work. James
Smart contributed a number of Fibre Channel changes and Jeremy Fitzhardinge
merged the core Xen code.
Once again, we have put some effort into associating patches with the
companies that supported this work, with the results shown below. These
results should always be taken as approximations; we believe that they are
essentially correct, but patches do not come with Paid-for-by: headers, so
a certain amount of guessing is always required.
|Most active 2.6.23 employers|
|By lines changed|
|Solid Boot Ltd.||8937||1.3%|
Red Hat retains its place at the top of the by-changesets list, though its
percentage of changes has dropped a bit. By lines changed, developers
known to be working on their own time (the "None" entry) beat out all
corporate contributors. It is worth noting that much of lines-changed
count for those developers is, in fact, lines removed.
Looking at who added Signed-off-by: lines to patches is interesting,
especially if one looks at signoffs added by people other than the author
of the patch. In this way, one gets an idea of who the gatekeepers are.
There is a slight change to how this calculation was done this time around:
if a patch carried signoffs from both Linus Torvalds and Andrew Morton,
Linus's was not counted. As a result of how the process works, everything
that goes through Andrew gets a signoff from Linus; not counting those
signoffs gives a more accurate picture of how the review was actually done.
|Developers with the most signoffs (total 5653)|
|David S. Miller||381||6.6%|
|Mauro Carvalho Chehab||150||2.6%|
|John W. Linville||70||1.2%|
One question which comes up sometimes is: how do these numbers look for
specific parts of the kernel tree? Your editor duly hacked on his scripts
to generate this sort of information. Here is a summary of the results -
using the employer by-changesets numbers:
|Employer changeset contributions by subsystem|
|/arch (1428 total)|
|/block (103 total)|
|/Documentation (241 total)|
|/drivers (2762 total)|
|/fs (622 total)|
|Univ. of Michigan CITI||35||5.6%|
|/kernel (938 total)|
|/mm (261 total)|
|/net (833 total)|
From these numbers, one might conclude that Red Hat developers are strong
in the core kernel area, but they don't much like writing documentation.
There is a lot of "hobbyist" participation in the driver subtree - not a
particularly surprising result, since making a specific device work is a
common itch for developers to scratch. Academics like to play with
filesystems, as do, unsurprisingly, companies like Oracle and NetApp.
Beyond being approximate, all of the numbers shown above will change a bit
before the final 2.6.23 release, which is probably at least three weeks
away. The patches which will be merged in the coming weeks should all be
fixed, though, so the changes will, with any luck at all, be small. All
told, 2.6.23 shows an active kernel development community with
contributions from a large number of developers - and quite a few companies
which employ them. The kernel remains a vibrant and alive base on which to
build our free systems.
(Thanks are due to Greg Kroah-Hartman for his contributions to the scripts
used to generate these statistics).
to post comments)