|
|
Subscribe / Log in / New account

A look at the 3.12 development cycle

This article brought to you by LWN subscribers

Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

By Jonathan Corbet
October 23, 2013
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 Kamat2612.5%
Jingoo Han2412.3%
Mark Brown2092.0%
Greg Kroah-Hartman1971.9%
H Hartley Sweeten1601.5%
Alex Deucher1511.4%
Laurent Pinchart1401.3%
Daniel Vetter1381.3%
Fabio Estevam1141.1%
Chris Metcalf1031.0%
Dan Carpenter960.9%
Dave Chinner900.9%
Peter Hurley830.8%
Joe Perches800.8%
Ben Hutchings770.7%
Magnus Damm760.7%
Rafael J. Wysocki730.7%
Lars-Peter Clausen730.7%
Trond Myklebust670.6%
Axel Lin650.6%
By changed lines
Larry Finger9290812.6%
Jesse Brandeburg305204.2%
Greg Kroah-Hartman297404.0%
H Hartley Sweeten259323.5%
Alex Deucher180262.5%
Ben Hutchings176602.4%
Rob Clark157032.1%
Bradley Grove156872.1%
Dave Chinner150992.1%
Scott Kilau147122.0%
Lidza Louina134741.8%
Laurent Pinchart116761.6%
Rajendra Nayak108661.5%
Chris Metcalf89241.2%
Tomi Valkeinen88811.2%
Feng-Hsin Chiang68130.9%
Yuan-Hsin Chen68130.9%
Ambresh K55280.8%
Hans Verkuil53850.7%
Atul Deshmukh48490.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
Intel10289.8%
(None)9649.2%
Linaro7327.0%
Red Hat7076.7%
(Unknown)6095.8%
Samsung4924.7%
IBM3903.7%
Freescale2562.4%
Renesas Electronics2492.4%
Texas Instruments2452.3%
Linux Foundation2252.1%
SUSE2062.0%
Oracle1831.7%
Free Electrons1831.7%
(Consultant)1821.7%
AMD1781.7%
Vision Engraving1751.7%
Google1611.5%
Huawei Technologies1241.2%
Broadcom1201.1%
By lines changed
(None)13413418.3%
Intel612278.3%
Red Hat498206.8%
Linux Foundation329554.5%
Vision Engraving268483.7%
Linaro260813.5%
Texas Instruments245183.3%
AMD243893.3%
(Unknown)229273.1%
Renesas Electronics206562.8%
Outreach Program for Women196492.7%
Solarflare Comm.183032.5%
ATTO Technology156882.1%
Digi International147202.0%
Faraday Technology136261.9%
IBM135541.8%
Samsung130831.8%
Tilera122561.7%
Freescale121041.6%
SUSE112651.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.

[Time
zones plot] 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
KernelReleases/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]

> 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%

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]

Summer time adds one.

A look at the 3.12 development cycle

Posted Oct 23, 2013 21:56 UTC (Wed) by pjtait (subscriber, #17475) [Link]

As confirmed by looking at the contributions from PST (UTC-8).

A look at the 3.12 development cycle

Posted Oct 23, 2013 14:49 UTC (Wed) by niner (subscriber, #26151) [Link]

Africa uses the same time zones as Europe. Are there no African kernel hackers?

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]

92908 lines of code for a driver is interesting, considering that presumably there is already a networking subsystem. I wonder which driver is the largest one in size.

A look at the 3.12 development cycle

Posted Oct 23, 2013 18:15 UTC (Wed) by nix (subscriber, #2304) [Link]

If you ignore networking drivers, one of the graphics drivers would win by a mile:

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]

In case of nouveau you didn't count subdirectories. For Linux 3.11:

$ 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]

Hm. OK, my oneliner was buggy. Thank you for re-emphasising my point!

A look at the 3.12 development cycle

Posted Oct 29, 2013 22:00 UTC (Tue) by BenHutchings (subscriber, #37955) [Link]

Most of the wireless drivers in staging include their own snapshot of the 802.11 stack (at least initially).

A look at the 3.12 development cycle

Posted Oct 23, 2013 18:26 UTC (Wed) by Lumag (subscriber, #22579) [Link]

+4 is European part of Russia (and also Saudi/Iraq/Syria + some Africa countries).

A look at the 3.12 development cycle

Posted Oct 23, 2013 20:11 UTC (Wed) by Tara_Li (guest, #26706) [Link]

With regards to the Devs with most changesets, and Devs with most lines - is there perhaps an option to look at how lines per changeset might affect that, as a Dev might have one particularly large changeset with a lot of lines that would bump her up one list, and not the other...

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]

This stuff is just for code accountants. According to git blame on sg.c the LWN editor was responsible for a single right brace in 2008?? [I guess some else changed the rest of his patch.]

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]

I can't help but agree. Well-written code tends to be much shorter than badly-written one, so the LoC numbers mean nothing. And what's even worse is that they might lead people (e. g. hiring managers) to the wrong conclusions about who is productive and who isn't. I think they're therefore worse than useless. Sorry Jon :-(

Still useful

Posted Oct 23, 2013 21:04 UTC (Wed) by david.a.wheeler (guest, #72896) [Link]

I suspect that a lot of code written to take "as many lines as possible" would be rejected, especially since there's an established format. So while lines of code are only a rough estimate of effort, lines of code are still strongly correlated with effort.

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]

If hiring management looks at LoC to hire, it is them to blame for demise of their company. IMO, just contributing to the kernel is enough for most positions, but more LoC also means revealing more about the talent, just more material to look in the eyes of the wise :)

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]

Well, one thing that would interest me is checking _negative_ metrics - how many patches were reverted? What's the distribution of CVEs among git blame? The main problem I see there is that while these are 'negative' metrics in the sense of 'there was a problem' they'd likely get interpreted in the sense of 'this person is a problem'.

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]

> Why not look for the best bug fix and reward the really hard work.

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]

It should be possible to improve the time-zone-based estimates significantly by correlating date with time zone: the combination of the two along with the tzdata time zone database should mostly distinguish between adjacent time zones that might or might not have a DST off-by-one error.

A look at the 3.12 development cycle

Posted Oct 24, 2013 11:07 UTC (Thu) by jnareb (subscriber, #46500) [Link]

> It should be possible to improve the time-zone-based estimates significantly by correlating date with time zone: the combination of the two along with the tzdata time zone database should mostly distinguish between adjacent time zones that might or might not have a DST off-by-one error.

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]

"improve", not "perfect".

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]

Except those in the southern hemisphere, which are just now entering summer time; Sydney just moved from +10 to +11 at the beginning of October and Rio moved to -2 a week and a half ago.

http://www.timeanddate.com/time/dst/2013.html

A look at the 3.12 development cycle

Posted Oct 24, 2013 14:18 UTC (Thu) by r.g.b. (guest, #64275) [Link]

Newfoundland(Saint John's) is UTC -3:30(-2:30 daylight savings), so nix that from the graph. Atlantic Canada and Labrador are UTC-3:00 at the moment in Daylight savings, so that graph could conceivably include New Brunswick (Frederickton, Moncton, Saint John), Nova Scotia(Halifax) and PEI(Charlottetown). There isn't much in Labrador(largest town of 8,000).

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]

I personally think time zones have no place in the commit history. I don’t know why Git includes them. I’ve been using this patch in my Git builds for a while now:

--- 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);
}


Copyright © 2013, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds