[go: up one dir, main page]

|
|
Log in / Subscribe / Register

Some numbers from the 4.19 development cycle

By Jonathan Corbet
October 7, 2018
The release of 4.19-rc6 on September 30 is an indication that the 4.19 development cycle is heading toward its conclusion. Naturally, that means it's time to have a look at where the contributions for this cycle came from. The upheavals currently playing out in the kernel community do not show at this level, but there are some new faces to be seen in the top contributors this time around.

As of this writing, 13,657 non-merge changesets have found their way into the mainline for 4.19. That makes this development cycle the busiest since 4.15, but only by a little bit; the patch volume in recent cycles has been remarkably constant:

CycleChangesets
4.1514,866
4.1613,630
4.1713,541
4.1813,283
4.1913,657(so far)

The changes in 4.19 were contributed by 1,710 developers, again a typical number; 253 of those developers were contributing to the kernel for the first time. The last two development cycles both removed more lines of code from the kernel than they added; that trend has come to a screeching halt in 4.19, which added 307,000 lines.

The most active 4.19 developers were:

Most active 4.19 developers
By changesets
John Whitmore2221.6%
Chris Wilson2081.5%
Gustavo A. R. Silva2051.5%
Colin Ian King1781.3%
Arnd Bergmann1551.1%
Christoph Hellwig1321.0%
Takashi Iwai1240.9%
Todd Poynor1160.8%
Bart Van Assche1100.8%
Ville Syrjälä1040.8%
Paul E. McKenney1010.7%
Michael Straube1010.7%
Brian Foster900.7%
Hans de Goede860.6%
Jason Gunthorpe860.6%
Boris Brezillon850.6%
Geert Uytterhoeven830.6%
Jerome Brunet790.6%
Jakub Kicinski780.6%
YueHaibing770.6%
By changed lines
Jeykumar Sankaran321384.8%
Richard Fitzgerald143902.2%
Jason Cooper114151.7%
Steven J. Hill100081.5%
Stanislaw Gruszka86861.3%
Darrick J. Wong83961.3%
Christoph Hellwig83661.3%
Simon Que80831.2%
Jerome Brunet77021.2%
Jiri Pirko65971.0%
Gao Xiang64641.0%
Jason Gunthorpe63331.0%
Rob Clark62200.9%
Lorenzo Bianconi60320.9%
Chris Wilson59700.9%
Linus Walleij56420.9%
Srinivas Kandagatla51700.8%
Benjamin Herrenschmidt51500.8%
Jordan Crouse51140.8%
David Lechner50630.8%

The ranks of the top contributors include some new names this time around. John Whitmore's work was entirely focused on improving two Realtek drivers in the staging tree. Chris Wilson made many changes to the i915 graphics driver, Gustavo A. R. Silva and Colin Ian King made small cleanups all over the tree, and Arnd Bergmann made significant fixes all over, many as part of the larger year-2038 readiness effort.

On the "lines changed" side, Jeykumar Sankaran added a graphics driver for SDM845 chipsets. Richard Fitzgerald added support for some Cirrus Logic codecs, Jason Cooper removed the unloved Skein and Threefish crypto algorithms from the staging tree, Steven Hill cleaned up the MIPS Octeon architecture code, and Stanislaw Gruszka contributed the MediaTek mt76x0 driver.

Work on 4.19 was supported by a minimum of 230 employers, the most active of which were:

Most active 4.19 employers
By changesets
Intel12949.5%
(None)11808.6%
Red Hat9707.1%
IBM6744.9%
(Unknown)6624.8%
Linaro6044.4%
Mellanox5614.1%
AMD5464.0%
Google5414.0%
SUSE4953.6%
Huawei Technologies3902.9%
(Consultant)3092.3%
Renesas Electronics2942.2%
Bootlin2912.1%
ARM2722.0%
Oracle2501.8%
Linux Foundation2351.7%
Canonical2251.6%
NXP Semiconductors2041.5%
Code Aurora Forum1901.4%
By lines changed
(None)562018.5%
Code Aurora Forum536448.1%
Intel529378.0%
Red Hat442226.7%
Mellanox356935.4%
Linaro355915.4%
IBM260923.9%
Google249963.8%
AMD206023.1%
(Unknown)191362.9%
Huawei Technologies172302.6%
(Consultant)161992.4%
Cirrus Logic145652.2%
SUSE136852.1%
Cavium133382.0%
Oracle133092.0%
BayLibre118541.8%
ARM108971.6%
Renesas Electronics107031.6%
Facebook100821.5%

One thing that jumps out is the amount of work that came from developers who were not working for anybody else. That number is still low by long-term historic standards (it was 12% for 3.0, for example), but is higher than it has been in recent times. There were 116 developers known to be working on their own time, or just under 7% of the developers working on the kernel; they contributed 8.5% of the total work.

With regard to testing and reviewing, the numbers this time around look like this:

Test and review credits in 4.19
Tested-by
Pavel Machek405.5%
Andrew Bowers273.7%
Alexandre Courbot263.6%
Arnaldo Carvalho de Melo263.6%
Joel Stanley233.2%
Shakeel Butt172.4%
Neil Brown152.1%
Hans de Goede141.9%
Tony Brelinski131.8%
Stan Johnson121.7%
Jiri Kosina111.5%
Song Liu101.4%
Randy Dunlap101.4%
Peter Rosin91.2%
Matthias Kaehlcke71.0%
Lucas Stach71.0%
Hanjun Guo71.0%
Ganapatrao Kulkarni71.0%
Dave Penkler71.0%
Aaron Brown71.0%
Reviewed-by
Rob Herring1853.8%
Darrick J. Wong1442.9%
Christoph Hellwig1342.7%
Christian König1012.1%
Andrew Morton911.8%
Alex Deucher851.7%
Geert Uytterhoeven771.6%
Simon Horman661.3%
David Sterba631.3%
Boris Brezillon621.3%
Tony Cheng611.2%
Andy Shevchenko571.2%
Tvrtko Ursulin571.2%
Daniel Vetter531.1%
Quentin Monnet531.1%
Ville Syrjälä521.1%
Rodrigo Vivi491.0%
Harry Wentland491.0%
Fabio Estevam491.0%

Of the 13,657 patches merged for 4.19, 659 carried Tested-by tags — about 5% of the total. 4,085 (30%) carried Reviewed-by tags. The following chart shows the trends in the use of these tags in recent years:

test/review tag usage
chart

As can be seen in this plot, the percentage of patches carrying Tested-by tags is at best flat over the 4.x series (which began in 2015). If one looks further back to 3.1 in late 2011, though, 3.6% of patches carried those tags, so there has been a bit of growth over that period. Reviewed-by tags, instead, are clearly appearing in more patches over time as more subsystems require them. That number, too, is up significantly from 3.1, where only 8.7% of patches had such tags. Kernel developers may be slow to adopt change, but some things do eventually change over time.

What doesn't seem to change is that the kernel-development machine continues to crank out releases integrating vast amounts of change on a predictable basis. The community is in a period of change in a number of ways, but it is to be expected that this record, which has held steady for many years now, will continue into the future.

Index entries for this article
KernelReleases/4.19


to post comments

Tested-by...

Posted Oct 9, 2018 13:41 UTC (Tue) by jani (subscriber, #74547) [Link] (3 responses)

Our CI machinery crunches through all patch series sent to our development mailing list, and a passing pre-merge test result is required before the patches get applied. Since this is our documented merge criteria, I've resisted the suggestions to add something along the lines of "Tested-by: The Intel Gfx CI Team" to every single patch we apply. I'm wondering if we should change that to 1) highlight that the patches passed quite a bit of testing, and 2) give credit to people to whom credit is due (although you can't really single out anyone individually). With that, we'd top the Tested-by column by quite some margin...

Tested-by...

Posted Oct 9, 2018 14:55 UTC (Tue) by seanpaul (guest, #70610) [Link] (2 responses)

In a somewhat similar vein, if I'm committing a change, I tend not to put the R-b tag on it since it'll already have my SoB. Do the metrics above take into account that if committer != author, review has likely happened?

Tested-by...

Posted Oct 11, 2018 8:08 UTC (Thu) by geert (subscriber, #98403) [Link] (1 responses)

No they don't. The metrics above only count explicitly-added Rb tags.

BTW, I do the same as you do: if I queue someone's patch, it'll have my SoB, but not my Rb.

Tested-by...

Posted Oct 17, 2018 11:12 UTC (Wed) by alex (subscriber, #1355) [Link]

Having been generating this graph for another project I've been using the metric of patches with only a single s-o-b and no tested/reviewed tags.


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