A look at the 3.12 development cycle
LWN.net needs you! Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing |
As of this writing, the 3.12-rc6 prepatch has been released, Linus seems happy with the state of the kernel, and, in general, there are few reports of problems on the mailing lists. If things continue to stabilize, the 3.12 cycle might be a short one, even by recent standards. So, clearly, it's time to get the traditional development statistics article out there.
There have been 10,480 non-merge changesets pulled into the mainline repository during this cycle (so far). That means that 3.12 may be the slowest cycle since 3.6 which, almost exactly one year ago, came out with 10,247 changesets. An unscientific look at recent release history suggests that kernels released in the (northern hemisphere) fall tend to include fewer changesets than those released at other times of the year, possibly reflecting lower productivity while developers take time off over the summer.
That said, 10,480 changesets is still quite a bit of work. Those changesets were contributed by 1,259 developers (a typical number for recent kernels), added 601,000 lines of code, and removed 279,000 for a net gain of 322,000 lines. The most active developers in this cycle were:
Most active 3.12 developers
By changesets Sachin Kamat 261 2.5% Jingoo Han 241 2.3% Mark Brown 209 2.0% Greg Kroah-Hartman 197 1.9% H Hartley Sweeten 160 1.5% Alex Deucher 151 1.4% Laurent Pinchart 140 1.3% Daniel Vetter 138 1.3% Fabio Estevam 114 1.1% Chris Metcalf 103 1.0% Dan Carpenter 96 0.9% Dave Chinner 90 0.9% Peter Hurley 83 0.8% Joe Perches 80 0.8% Ben Hutchings 77 0.7% Magnus Damm 76 0.7% Rafael J. Wysocki 73 0.7% Lars-Peter Clausen 73 0.7% Trond Myklebust 67 0.6% Axel Lin 65 0.6%
By changed lines Larry Finger 92908 12.6% Jesse Brandeburg 30520 4.2% Greg Kroah-Hartman 29740 4.0% H Hartley Sweeten 25932 3.5% Alex Deucher 18026 2.5% Ben Hutchings 17660 2.4% Rob Clark 15703 2.1% Bradley Grove 15687 2.1% Dave Chinner 15099 2.1% Scott Kilau 14712 2.0% Lidza Louina 13474 1.8% Laurent Pinchart 11676 1.6% Rajendra Nayak 10866 1.5% Chris Metcalf 8924 1.2% Tomi Valkeinen 8881 1.2% Feng-Hsin Chiang 6813 0.9% Yuan-Hsin Chen 6813 0.9% Ambresh K 5528 0.8% Hans Verkuil 5385 0.7% Atul Deshmukh 4849 0.7%
Sachin Kamat and Jingoo Han both contributed a wide range of cleanup patches all over the driver subsystem. Mark Brown continues to do substantial work in the sound, SPI, and regulator driver subsystems, among others. Greg Kroah-Hartman integrated a number of low-level device model changes, along with Lustre filesystem fixups and more. H. Hartley Sweeten's crusade to clean up the Comedi drivers continues; that work resulted in the removal of over 21,000 lines of code this time around.
On the "lines changed" side, Larry Finger added the Realtek RTL8188EU wireless network driver to the staging tree. Jesse Brandeburg added the Intel i40e network driver. Greg's and Hartley's work was, in both cases, dominated by the removal of large amounts of unneeded driver code, while Alex Deucher continues to add functionality to the Radeon driver.
A total of 212 employers (that we know of) supported work on the 3.12 release. The most active of those were:
Most active 3.12 employers
By changesets Intel 1028 9.8% (None) 964 9.2% Linaro 732 7.0% Red Hat 707 6.7% (Unknown) 609 5.8% Samsung 492 4.7% IBM 390 3.7% Freescale 256 2.4% Renesas Electronics 249 2.4% Texas Instruments 245 2.3% Linux Foundation 225 2.1% SUSE 206 2.0% Oracle 183 1.7% Free Electrons 183 1.7% (Consultant) 182 1.7% AMD 178 1.7% Vision Engraving 175 1.7% 161 1.5% Huawei Technologies 124 1.2% Broadcom 120 1.1%
By lines changed (None) 134134 18.3% Intel 61227 8.3% Red Hat 49820 6.8% Linux Foundation 32955 4.5% Vision Engraving 26848 3.7% Linaro 26081 3.5% Texas Instruments 24518 3.3% AMD 24389 3.3% (Unknown) 22927 3.1% Renesas Electronics 20656 2.8% Outreach Program for Women 19649 2.7% Solarflare Comm. 18303 2.5% ATTO Technology 15688 2.1% Digi International 14720 2.0% Faraday Technology 13626 1.9% IBM 13554 1.8% Samsung 13083 1.8% Tilera 12256 1.7% Freescale 12104 1.6% SUSE 11265 1.5%
This is not the first time that Red Hat has been upstaged as the top corporate contributor, but it has never been as low as #4. Linaro, instead, continues to increase its contributions to the kernel, as do a number of mobile and embedded companies. The number of changes from volunteers is down slightly, in keeping with the steady trend over the last few years. Developers brought in through the Outreach Program for Women continued to contribute significantly during this cycle.
Your editor is often asked to summarize the origin of kernel patches geographically — how many are coming from $COUNTRY? That question can be hard to answer. But there is another question that is a bit easier: every commit in the repository has a time stamp, and that time stamp includes a time zone. It is a relatively easy matter to pass over a range of commits and summarize which time zones appear most often.
The result of this work appears in the plot to the right. One should bear in mind that this data is necessarily somewhat noisy; there is nothing that constrains developers' machines to have their time set in the zone where they physically reside. Daylight saving time can also add noise to the picture. In the aggregate, though, there are some interesting things to be seen here.
Starting at the top, +10 includes parts of Russia, parts of Indonesia, and, most importantly for this study, parts of Australia. The +9 zone, instead, is mainly Japan and Korea, while +8 is Western Australia and China. About 15% of the changes to 3.12 came from those three time zones.
There is only one country that lives in +5:30 — India. The number of contributions from India has been growing for a while; it's now 6% of the total. Going west from there, +2 to +4 will be dominated by continental Europe, with the central European time zone accounting for 23% of the changes in 3.12. The UK and Ireland, at +1, put in another 10%.
The western hemisphere (negative) zones will be dominated by North America. The -3 zone, however, only covers Newfoundland and Labrador in the northern hemisphere; the relative scarcity of kernel hackers in that part of the world leads one to conclude that 5% of the patches for 3.12 came from Brazil and Argentina, both of which reside in that zone. Your editor's time zone (-6), alas, was the source of only 1% of the changes going into this release; it must be time to pull together some white-space patches to improve that situation.
To state things more generally: one could say that Asia and Australia
contributed 22% of the changes to 3.12, while Europe contributed 43%, North
America 30%, and South America 5%. These numbers are clearly
approximate, but they probably do not hugely distort the reality. The
Linux kernel project truly is global in scope, with developers representing
much of the planet participating. All told, it has the appearance of a
healthy and thriving community.
Index entries for this article | |
---|---|
Kernel | Releases/3.12 |
(Log in to post comments)
A look at the 3.12 development cycle
Posted Oct 23, 2013 11:45 UTC (Wed) by bokr (subscriber, #58369) [Link]
Your editor's time zone (-6), alas, was the source of only 1% of the changes going into this release; it must be time to pull together some white-space patches to improve that situation.That makes me wonder how the statistics would look for changes just to the residue after stripping all comments and canonicalizing white space.
A look at the 3.12 development cycle
Posted Oct 23, 2013 12:12 UTC (Wed) by tdalman (guest, #41971) [Link]
AFAIK UK and Ireland are at GMT+0, while western Europe is at +1. That said, the contribution from UK and Ireland is at about 2%, right ?
A look at the 3.12 development cycle
Posted Oct 23, 2013 12:23 UTC (Wed) by rvfh (guest, #31018) [Link]
A look at the 3.12 development cycle
Posted Oct 23, 2013 21:56 UTC (Wed) by pjtait (subscriber, #17475) [Link]
A look at the 3.12 development cycle
Posted Oct 23, 2013 14:49 UTC (Wed) by niner (subscriber, #26151) [Link]
African developers
Posted Oct 23, 2013 15:07 UTC (Wed) by corbet (editor, #1) [Link]
Very few, alas. I feel confident in saying that the number is at least two orders of magnitude less than Europe's, so they are pretty much in the noise for the purposes of this (already noisy) exercise.
African developers
Posted Oct 28, 2013 8:01 UTC (Mon) by robbe (guest, #16131) [Link]
Assuming you didn't mean binary orders of magnitude, that is less than six developers. That's really some room for improvement!... Asia ... Women ... Africa ........ World Domination ↑ └─ we are here
A look at the 3.12 development cycle
Posted Oct 23, 2013 17:37 UTC (Wed) by dashesy (guest, #74652) [Link]
A look at the 3.12 development cycle
Posted Oct 23, 2013 18:15 UTC (Wed) by nix (subscriber, #2304) [Link]
radeon: 181934
i915: 69779
gma500: 32005
nouveau: 23347
(the ugly oneliner I'm using for this is just looking at all files under particular directories, so I can't look at network drivers so accurately -- but even wireless drivers seem to come in at the same sort of size as nouveau, and *much* smaller than radeon.)
A look at the 3.12 development cycle
Posted Oct 23, 2013 19:50 UTC (Wed) by mslusarz (guest, #58587) [Link]
$ find drivers/gpu/drm/nouveau/ -name "*.[ch]" -exec cat {} \;|wc -l
96886
A look at the 3.12 development cycle
Posted Oct 30, 2013 0:00 UTC (Wed) by nix (subscriber, #2304) [Link]
A look at the 3.12 development cycle
Posted Oct 29, 2013 22:00 UTC (Tue) by BenHutchings (subscriber, #37955) [Link]
A look at the 3.12 development cycle
Posted Oct 23, 2013 18:26 UTC (Wed) by Lumag (subscriber, #22579) [Link]
A look at the 3.12 development cycle
Posted Oct 23, 2013 20:11 UTC (Wed) by Tara_Li (guest, #26706) [Link]
It might be interesting to look at the differences in what small changesets do, and what large ones do, other than, of course, in drivers. I expect most of the large ones get covered, with descriptions of what ABI is getting munged, or what subsystem is getting ripped out and replaced, but I expect the janitors show up in the small changesets.
A look at the 3.12 development cycle
Posted Oct 23, 2013 20:32 UTC (Wed) by dougg (subscriber, #1894) [Link]
Why not look for the best bug fix and reward the really hard work.
A look at the 3.12 development cycle
Posted Oct 23, 2013 20:53 UTC (Wed) by HelloWorld (guest, #56129) [Link]
Still useful
Posted Oct 23, 2013 21:04 UTC (Wed) by david.a.wheeler (subscriber, #72896) [Link]
You could try using a SLOC-counting tool that strips out comments and blank lines.
A look at the 3.12 development cycle
Posted Oct 23, 2013 21:45 UTC (Wed) by dashesy (guest, #74652) [Link]
A look at the 3.12 development cycle
Posted Oct 24, 2013 8:58 UTC (Thu) by corbet (editor, #1) [Link]
Trust me, I know that these are poor metrics. I sure wish I could come up with a better one that would scale to a project with tens of thousands of commits every year...
A look at the 3.12 development cycle
Posted Oct 29, 2013 21:50 UTC (Tue) by eternaleye (guest, #67051) [Link]
The _benefit_ is that they might indicate places where more documentation, more review, or other such things are needed. If, for instance, (random subsystem, not actually based on anything) networking code sees a higher rate of reversions or CVEs per commit or changed line, that could be a damn good signal that there needs to be some examination of why it happens. It could be that networking code is just plain more exposed as an attack surface, but it could also be something resolvable.
From another angle, debiting reversions against the reverted patch author's commits and lines of code could be interesting as a reverted commit is a no-op in terms of useful change, even though (as Linus has had to point out at times) it's certainly not a no-op in terms of code.
Another interesting thought is the number of first-time contributors per kernel, or new email domains (likely correlated to new companies becoming involved in development) - those would be well worth bringing up, and acknowledging them could have beneficial effects by rewarding participation (and providing a signal to people like me of companies that might be worth looking into/supporting/checking out the products of).
A look at the 3.12 development cycle
Posted Oct 24, 2013 21:27 UTC (Thu) by jani (subscriber, #74547) [Link]
In this respect, it would be interesting to see similar statistics for commits backported to stable kernels.
A look at the 3.12 development cycle
Posted Oct 24, 2013 0:07 UTC (Thu) by josh (subscriber, #17465) [Link]
A look at the 3.12 development cycle
Posted Oct 24, 2013 11:07 UTC (Thu) by jnareb (subscriber, #46500) [Link]
This assumes that all countries in the same timezone have their DST switch times (some countries do not use DST, some switch at different dates though differences are small) and DST offset synchronized (compare northern and southern hemisphere DST).
A look at the 3.12 development cycle
Posted Oct 24, 2013 12:32 UTC (Thu) by josh (subscriber, #17465) [Link]
A look at the 3.12 development cycle - time zones
Posted Oct 25, 2013 16:29 UTC (Fri) by giraffedata (guest, #1954) [Link]
I believe essentially all places that use summer time at all were using it throughout the release cycle.Also, there aren't enough contributors in places that don't use summer time to make a noticeable difference in the histogram.
A look at the 3.12 development cycle - time zones
Posted Oct 31, 2013 3:04 UTC (Thu) by gnu_andrew (subscriber, #49515) [Link]
A look at the 3.12 development cycle
Posted Oct 24, 2013 14:18 UTC (Thu) by r.g.b. (guest, #64275) [Link]
Having said that, Brazil does seem more likely.
A look at the 3.12 development cycle
Posted Oct 25, 2013 7:49 UTC (Fri) by brother_rat (subscriber, #1895) [Link]
There is only one country that lives in +5:30 — India.and Sri Lanka.
No Time Zones
Posted Nov 3, 2013 6:16 UTC (Sun) by ldo (guest, #40946) [Link]
--- date.c-orig 2008-05-28 19:56:46.000000000 +1200
+++ date.c 2008-05-31 00:48:17.000000000 +1200
@@ -611,8 +611,12 @@
time(&now);
+#if 0
offset = tm_to_time_t(localtime(&now)) - now;
offset /= 60;
+#else
+ offset = 0;
+#endif
date_string(now, offset, buf, bufsize);
}