[go: up one dir, main page]

|
|
Log in / Subscribe / Register

Who wrote 3.15 through 3.17

By Jonathan Corbet
September 24, 2014
When writing up the 3.14 development statistics, your editor publicly wondered if compiling those reports for every development cycle made sense. That question was followed by a bit of a break; there were no "who wrote..." articles for the 3.15 or 3.16 development cycles. Now that just over six months have passed and the 3.17 kernel is nearing release, it seems like it may be time to take another look at how the kernel development process is working.

Since 3.14, kernel release activity has looked like this:

Version Date CSets Devs Lines (thousands)
Added Removed Delta
3.15 Jun 8 13,722 1492 1066 707 360
3.16 Aug 3 12,804 1478 578 329 249
3.17 Sep 28* 12,153 1408 692 708 -16
3.15–17 38,679 2546 2336 1744 593

A few interesting things jump out of these numbers. The 3.12 cycle had contributions from 1257 developers. By 3.13, that had increased to 1339, and 3.14 had patches from exactly 1400 developers. So the count of developers contributing to each kernel release, which had hovered in the 1200's for some time, has shown a significant increase. The active kernel development community continues to grow.

The kernel itself also continues to grow, but 3.17 looks like a rare exception. Thanks to the removal of a bunch of unloved code from the staging tree, 3.17 is actually smaller than its predecessor. That has only happened one other time in the history of the Linux kernel; 2.6.36 was smaller than 2.6.35 thanks to the removal of a pile of defconfig files. The overall trend remains unchanged, though; the kernel grew by almost 600,000 lines in the last three releases.

As of 3.17-rc6, Linus was thinking that he would be able to do the 3.17 final release on September 28. Should that schedule hold, the 3.17 kernel will have been produced in a mere 56 days — as was 3.16. Your editor has remarked on the trend of the shortening kernel release cycle for a while. Here is what that trend looks like now (again, assuming the 3.17 release is not delayed):

[Development cycle length chart]

So the kernel development cycle, it seems, continues to get shorter. How much longer that trend can continue is unclear, though; there must be a minimum period required to get a high-quality release together. One other potentially interesting point: it should be remembered that the final stabilization of the 3.15 release overlapped with the 3.16 merge window. That probably had little to do with why the 3.15 cycle took longer than many others; it was the result of some difficult-to-find last-minute bugs. But one could argue that the 3.16 development cycle should really be counted as being one week longer than the release dates would indicate.

Contributors

As can be seen from the table above, 38,679 non-merge changesets were pulled into the mainline repository for the 3.15–3.17 development cycles. Of the 2546 developers who contributed changes during this time, the most active were:

Most active developers, 3.15–3.17
By changesets
Hartley Sweeten9192.4%
Jes Sorensen7672.0%
Malcolm Priestley5441.4%
Fabian Frederick3821.0%
Navin Patidar3781.0%
Laurent Pinchart3300.9%
Sachin Kamat3270.8%
Russell King3160.8%
Axel Lin3010.8%
Johan Hedberg3000.8%
Geert Uytterhoeven2960.8%
Daniel Vetter2780.7%
Takashi Iwai2750.7%
Jingoo Han2650.7%
Thomas Gleixner2600.7%
Alexander Shiyan2400.6%
Ville Syrjälä2350.6%
Joe Perches2330.6%
Tejun Heo2310.6%
Lars-Peter Clausen2260.6%
By changed lines
Tomi Valkeinen31889410.9%
Kristina Martšenko1651025.6%
Larry Finger1648695.6%
Andrzej Pietrasiewicz1080363.7%
Mauro Carvalho Chehab712532.4%
Greg Kroah-Hartman682602.3%
Dave Chinner482671.6%
Devin Heitmueller461251.6%
Malcolm Priestley352311.2%
Jes Sorensen294121.0%
Navin Patidar288711.0%
Hans Verkuil278130.9%
Ben Skeggs262930.9%
Mark Hounschell242850.8%
Ken Cox232130.8%
Hartley Sweeten212460.7%
Jason Cooper203440.7%
Linus Walleij198980.7%
Jake Edge182180.6%
Maxime Ripard146690.5%

As is usually the case, Hartley Sweeten contributed more changesets than any other developer; all of those were against the COMEDI drivers in the staging tree. All told, nearly 6,000 patches have been applied against just that subsystem since its entry into staging. Jes Sorensen's work was nearly all against the rtl8723au driver, while Malcolm Priestly worked on the vt6656 driver; both of those drivers are also in the staging tree. Fabian Frederick contributed cleanups throughout the kernel tree, while Navin Patidar focused on the rtl8188eu driver which, unsurprisingly, is also in the staging tree.

In the "lines changed" column, Tomi Valkeinen reached the top with extensive work on the ARM OMAP architecture code and related device tree files. Kristina Martšenko removed 14 drivers from the staging tree, making her the developer who removed the most code during this time. Larry Finger continues his work to rationalize the Realtek wireless drivers in the staging tree, Andrzej Pietrasiewicz did a lot of work in the USB gadget driver, and Video4Linux subsystem maintainer Mauro Carvalho Chehab did extensive work throughout that tree.

The 3.15–3.17 development cycles saw contributions from at least 312 employers, the most active of whom were:

Most active employers, 3.15–3.17
By changesets
(None)449211.6%
Intel408810.6%
Red Hat35779.2%
(Unknown)34098.8%
Linaro17024.4%
Samsung16464.3%
SUSE12433.2%
IBM10502.7%
(Consultant)10162.6%
Texas Instruments9422.4%
Vision Engraving Systems9192.4%
Google7632.0%
Renesas Electronics7531.9%
Free Electrons7531.9%
Freescale6201.6%
C-DAC4001.0%
Oracle3901.0%
Imagination Technologies3610.9%
NVidia3550.9%
FOSS Outreach Program for Women3360.9%
By lines changed
(None)40817613.9%
Texas Instruments35705812.2%
(Unknown)33876011.6%
Red Hat2592648.8%
Samsung2496138.5%
Intel1808696.2%
Linaro931253.2%
Linux Foundation689882.4%
SUSE522131.8%
(Consultant)459521.6%
IBM448091.5%
Free Electrons429171.5%
Cisco332541.1%
Freescale326361.1%
C-DAC304051.0%
Renesas Electronics299731.0%
Google299571.0%
Realtek278881.0%
NVidia272320.9%
COMPRO Intelligent Solutions247220.8%

As usual, this picture has remained relatively stable from one release to the next. Mildly notable is the increase in contributions from developers working on their own time, though it would be hard to say that the long-term trend toward decreasing volunteer contributions has ended at this point.

Reviews and conclusion

Finally, it can be interesting to look at who is attaching Reviewed-by tags to patches. That tag is meant both as an indicator that the patch has been reviewed and a means for crediting developers who perform those reviews. The developers with the most Reviewed-by tags during this period were:

Developers with the most Reviewed-by tags
Ian Abbott76611.0%
Josh Triplett2073.0%
Tomasz Figa1552.2%
Christoph Hellwig1422.0%
Ville Syrjälä1321.9%
Chris Wilson1231.8%
Johannes Berg1221.8%
Jesse Barnes1031.5%
Guenter Roeck981.4%
Pieter-Paul Giesberts921.3%
David Herrmann871.3%
Dave Chinner861.2%
Hartley Sweeten861.2%
Imre Deak841.2%
Alex Elder841.2%
Rodrigo Vivi801.2%
Alex Deucher741.1%
Damien Lespiau731.1%
Daniel (Deognyoun) Kim711.0%
Franky (Zhenhui) Lin661.0%

Ian Abbott, it seems, has reviewed 766 patches in the 182 days covered by these three development cycles — just over four patches every day, with no breaks for weekends or holidays. It turns out that almost all of those patches were the COMEDI changes submitted by Hartley Sweeten. Josh Triplett, instead, reviewed a wide range of changes from many developers; most of those were changes related to or involving read-copy-update. Tomasz Figa concerns himself with ARM-related changes, Christoph Hellwig is a longstanding reviewer of storage- and filesystem-related patches, and reviews changes to DRM (graphics) drivers.

What is not reflected here, of course, is the vast amount of patch review work that never results in a Reviewed-by tag. In fact, your editor would assert that this mechanism is not working as intended at this point. It is failing to document the bulk of the review work that is being done and serves mostly to highlight which developers make the effort to offer an explicit Reviewed-by tag.

To summarize: what has changed in the six months since LWN last published a set of development statistics? The answer is "not much." The kernel development process continues to roll along, producing releases in a fairly predictable schedule. The pace continues to increase, the community continues to grow, and the development cycle continues to shorten. These are all trends that we have seen for a while, so, to a great extent, it all looks like business as usual.

Index entries for this article
KernelReleases/3.15
KernelReleases/3.16
KernelReleases/3.17


to post comments

Who wrote 3.15 through 3.17

Posted Sep 25, 2014 11:51 UTC (Thu) by error27 (subscriber, #8346) [Link]

Ian Abbott really has done a fantastic job reviewing all of Hartley's changes. He has an amazing eye for detail.

One of the things that is a blessing and curse when dealing the open source is that if people start sending you patches then you have to deal with all of them. With comedi there really was a lot of patches to deal with.

The good news is that comedi is looking much better now and should be out of staging soonish. Hartley was saying which things he wanted to finish up first at kernel summit but I forget exactly what's left...

Who wrote 3.15 through 3.17

Posted Sep 25, 2014 15:02 UTC (Thu) by ssl (guest, #98177) [Link] (1 responses)

My coworker is amazed and bewildered, how much code people can output.

look at this:

Tomi Valkeinen 318894 10.9%
Kristina Martšenko 165102 5.6%
Larry Finger 164869 5.6%
Andrzej Pietrasiewicz 108036 3.7%
Mauro Carvalho Chehab 71253 2.4%
Greg Kroah-Hartman 68260 2.3%

By this measure, Tomi wrote (lines/days/ 8 hours) = 318894 / ~ 180 days since 3.14 / 8) = 221 lines of code per hour. How they can be so unbelievable fast? Are they superhumans? They have usb ports in head?

Who wrote 3.15 through 3.17

Posted Sep 25, 2014 15:37 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

Your co-worker is misinterpreting the statistics. The metric is lines changed, not new lines written. It seems likely to me that a sizeable chunk of that will have been the result of things like deletion, copy-and-paste, and/or search-and-replace, and even if it was "new lines written", it's not necessarily the case that the lines in questions were written (rather than merely introduced to the kernel) in that period.

Who wrote 3.15 through 3.17

Posted Sep 29, 2014 12:54 UTC (Mon) by zack (subscriber, #7062) [Link]

> Mildly notable is the increase in contributions from developers working on their own time, though it would be hard to say that the long-term trend toward decreasing volunteer contributions has ended at this point

But the mild increase is averaged over 3 releases this time. If we add to that picture the increase during 3.13, wouldn't that justify a slightly more optimistic take on the amount of volunteer contributions to the kernel? :-)

More seriously, can we haz historical graphs (maybe next time) on the percentage of per-company (including "none") contributions over time? That would be interesting to look at.

As usual, thanks for these awesome development statistics, Jon!

Who wrote 3.15 through 3.17

Posted Oct 3, 2014 18:59 UTC (Fri) by tomba (subscriber, #51091) [Link] (1 responses)

I didn't do "extensive work on the ARM OMAP architecture code and related device tree files" (well, I did, but not _that_ extensive), I just split the drivers/video/ into subdirs, and moved files around.

Maybe file renames shouldn't count to changed lines in the statistics?

Who wrote 3.15 through 3.17

Posted Oct 3, 2014 21:02 UTC (Fri) by tao (subscriber, #17563) [Link]

Reorganising things can (if it's done with some thought) be quite extensive and important, so I don't think renames shouldn't be in the statistics.

That said, maybe counting a rename as a one-line change might make more sense?


Copyright © 2014, 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