Some 5.12 development statistics
Patches were contributed to 5.12 by 1,873 developers, 262 of whom were first-time contributors; those are typical numbers, especially given the (relatively) small size of this cycle. The most active 5.12 developers were:
Most active 5.12 developers
By changesets Lee Jones 256 2.0% Chris Wilson 167 1.3% Pavel Begunkov 158 1.2% Vladimir Oltean 120 0.9% Christoph Hellwig 117 0.9% Jens Axboe 113 0.9% Arnd Bergmann 109 0.8% Andy Shevchenko 94 0.7% Ben Skeggs 91 0.7% Paul E. McKenney 85 0.7% Zheng Yongjun 81 0.6% Ard Biesheuvel 77 0.6% Dan Carpenter 75 0.6% Hans de Goede 70 0.5% Alexandre Belloni 69 0.5% Geert Uytterhoeven 65 0.5% Sean Christopherson 64 0.5% Jiri Olsa 61 0.5% Chuck Lever 60 0.5% Colin Ian King 59 0.5%
By changed lines Arnd Bergmann 65277 9.4% Po-Hao Huang 21723 3.1% Viresh Kumar 16782 2.4% Maximilian Luz 14520 2.1% Andy Shevchenko 13160 1.9% Pawel Laszczak 10605 1.5% Ard Biesheuvel 9837 1.4% Sean Wang 9392 1.4% Chris Wilson 9255 1.3% Damien Le Moal 8949 1.3% Vladimir Oltean 7948 1.1% Hannes Reinecke 7854 1.1% Srujana Challa 7786 1.1% Thomas Zimmermann 6983 1.0% Bjorn Andersson 6978 1.0% Lorenzo Bianconi 6282 0.9% Srinivas Kandagatla 6100 0.9% Paul Kocialkowski 6050 0.9% Yevgeny Kliteynik 5967 0.9% Rob Herring 5870 0.8%
As with 5.11, Lee Jones was the most active changeset contributor this time around; he continues to work to fix compiler and docs-build warnings throughout the tree. Chris Wilson worked on the Intel i915 graphics driver. Pavel Begunkov worked mostly within the io_uring subsystem, Vladimir Oltean made a lot of improvements within the networking subsystem, and Christoph Hellwig continues to clean up the code in (mostly) the block layer and filesystems.
Arnd Bergmann deleted support for a number of obsolete architectures and their associated drivers, reaching the top of the "lines changed" column by virtue of the amount of code removed. Po-Hao Huang contributed eight patches, mostly updating some machine-generated tables. Viresh Kumar removed support for the old, unused "oprofile" profiling mechanism, Maximilian Luz added support for Microsoft Surface devices, and Andy Shevchenko removed some unneeded Intel driver code.
Report, test, and review credits
The kernel community depends heavily on contributions beyond just code; that includes those who report problems, and those who test and review code. Kernel developers try to credit these contributions through the addition of tags to the relevant patches. The most active credited reporters of bugs fixed in 5.12 were:
Most active 5.12 bug reporters kernel test robot 184 16.1% Syzbot 111 9.7% Abaci Robot 107 9.4% Dan Carpenter 44 3.9% Hulk Robot 41 3.6% Stephen Rothwell 28 2.5% Randy Dunlap 19 1.7% Kent Overstreet 12 1.1% Guenter Roeck 11 1.0% TOTE Robot 11 1.0% Colin Ian King 9 0.8% Andrii Nakryiko 8 0.7% Juan Vazquez 7 0.6% Arnd Bergmann 6 0.5%
Here we see the increasing presence of automated testing systems, which are finding bugs before (one hopes) they affect users.
The most active testers and reviewers this time around were:
Test and review credits in 5.12
Tested-by Daniel Wheeler 67 7.1% Tony Brelinski 62 6.6% Matt Merhar 33 3.5% Nicolas Chauvet 32 3.4% Peter Geis 31 3.3% Arnaldo Carvalho de Melo 29 3.1% Dmitry Osipenko 26 2.8% Wolfram Sang 21 2.2% Karthik B S 19 2.0% Marek Szyprowski 16 1.7% Sean Nyekjaer 16 1.7% Boqun Feng 15 1.6%
Reviewed-by Christoph Hellwig 220 3.6% Rob Herring 146 2.4% Laurent Pinchart 132 2.2% David Sterba 121 2.0% Florian Fainelli 109 1.8% Lyude Paul 91 1.5% Linus Walleij 87 1.4% Josef Bacik 82 1.4% Andrew Lunn 79 1.3% Hans de Goede 70 1.2% Darrick J. Wong 69 1.1% Chris Wilson 64 1.1%
The top folks in the Tested-by column appear to be routinely testing patches from their work colleagues — something that is probably much more widely done without applying tags to that effect. Matt Merhar, Nicolas Chauvet, and Peter Geis have almost the same number of credits, which is not a coincidence: all three tend to show as having tested the same patches, almost all from a single author (example). The Reviewed-by column is more diverse, with a mix of active maintainers and others who clearly put a lot of time into the review task.
Employer support
Work on 5.12 was supported by 211 employers that we were able to identify; that is a small decrease from previous releases but is in line with the lower patch volume in general. The most active companies this time were:
Most active 5.12 employers
By changesets Intel 1425 10.9% (Unknown) 1012 7.8% Red Hat 872 6.7% Linaro 868 6.7% 752 5.8% Huawei Technologies 525 4.0% 477 3.7% (None) 475 3.6% AMD 403 3.1% NVIDIA 402 3.1% IBM 372 2.9% SUSE 358 2.8% (Consultant) 333 2.6% Oracle 306 2.4% Renesas Electronics 252 1.9% Arm 248 1.9% NXP Semiconductors 237 1.8% Pengutronix 191 1.5% MediaTek 173 1.3% Alibaba 170 1.3%
By lines changed Linaro 120694 17.4% Intel 80056 11.5% Red Hat 38249 5.5% 29108 4.2% (Unknown) 28976 4.2% NVIDIA 28766 4.1% (None) 26298 3.8% Realtek 22572 3.3% SUSE 20388 2.9% MediaTek 19872 2.9% Arm 16063 2.3% Marvell 15400 2.2% AMD 14753 2.1% Pengutronix 13744 2.0% Western Digital 12827 1.8% 11885 1.7% Code Aurora Forum 11768 1.7% NXP Semiconductors 11669 1.7% IBM 10799 1.6% Texas Instruments 10744 1.5%
Unsurprisingly, these numbers look a lot like what we saw for 5.11 — and numerous kernels before that. The biggest change is the result of the flurry of code-removal patches coming from Linaro, which ended up at the top of the "lines changed" column as a result.
The path into the mainline
![[Patch-flow graph]](https://static.lwn.net/images/2021/treeplot-5.12-t.svg)
While Linus Torvalds is ultimately responsible for pulling all of the
patches discussed here into the mainline, he handles few of them directly;
by far the bulk of all patches going into the kernel go through at least
one subsystem maintainer's repository. The path taken by patches can draw
an interesting picture of how our community actually works; how closely
does it match the hierarchical model that is often used to describe the
kernel community?
An email message typically passes through a number of servers between sender and recipient; each server normally adds a "Received" header marking that passage. Git commits, instead, are immutable and accumulate no such markings from the repositories through which they pass. What does happen, though, is the addition of merge commits when a set of commits from one repository is pulled into another. At least, that happens most of the time. Some projects suffer from a sort of merge phobia; they require rebasing and fast-forward merges that do not leave any signs in the history. The kernel does not suffer from this particular syndrome, though, so most pulls do result in the creation of a merge commit.
Git will, when creating this commit, put the beginnings of a message in the changelog that includes the tree from which the commits are being merged. Assuming the maintainer leaves that information in place, this message makes it possible to recreate the path taken by those commits; happily, almost all kernel maintainers leave that information in place.
The merge commit also contains information about the GPG key (if any) that was used to sign the tag at the head of the set of commits to pull. This, too, is useful information. In theory, all pull requests should include signed tags as a way of ensuring that the associated commits were actually marked, by a recognized kernel maintainer, for merging into the mainline. In practice, not all maintainers have bothered to sign their commits in this way. Torvalds does not insist on signatures for pulls from trees hosted on kernel.org, but does generally require them for repositories stored anywhere else.
The treeplot program, part of the gitdm suite of ugly data-mining hacks, can collect all of this information and turn it into a graph. The result of this work for the 5.12 kernel can be seen on the right; clicking on that image and displaying the result in a large window should yield something that is actually legible. Rectangles indicate repositories, and arrows show the flow of commits between them; the number next to each arrow indicates how many commits took that path during the 5.12 cycle. Black indicates the use of signed tags, red shows their absence.
The shape of this graph has changed slowly over the years; it is still quite flat with a large number of repositories being pulled directly into the mainline by Torvalds, but we are seeing more going through mid-level maintainers as well. A number of the larger subsystems — networking, graphics, and Arm systems, for example — feed patches through multiple layers of maintainers. The largest stream of commits into the mainline continues to pass through the networking repositories, which were the source of over 2,400 commits going into 5.12.
The networking repositories are also the largest source of commits that are not protected with a signed tag; this situation has persisted for some years. All told, though, of the 126 repositories that fed commits into 5.12, all but 15 were using signed tags, a significant increase from past years. It is somewhat ironic that one of the remaining trees eschewing cryptographic signatures is the crypto tree.
While Torvalds requires signed tags for pulls from sites like GitHub, it can be seen that some other maintainers do not. There are, as a result, a few unsigned pulls from public hosting sites that are making it into the mainline kernel by way of an intermediate maintainer.
In the end, though, the picture that emerges from all of the above is a community that, for all of its difficulties, still manages to incorporate large numbers of changes in a reliable and predictable way. There are few projects out there that can sustain the scale of the kernel community and produce a stable and usable result. As of this writing, there are 13,677 changesets queued in linux-next, most of which will be destined for 5.13, so the process seems unlikely to slow down anytime soon.
Update: the employer numbers have been adjusted slightly since the
initial publication of this article in response
to a report from Leon Romanovsky.
| Index entries for this article | |
|---|---|
| Kernel | Releases/5.12 |