Some 5.15 development statistics
Long-time readers of these summaries will note that the changeset total for 5.15 is relatively low; indeed, it's worth comparing it to the kernel's release history since 5.0 came out in early 2019:
Release Changesets Developers 5.0 12,808 1,712 5.1 13,034 1,707 5.2 14,024 1,716 5.3 14,605 1,846 5.4 14,619 1,802 5.5 14,350 1,885 5.6 12,665 1,712 5.7 13,901 1,878 5.8 16,306 1,991 5.9 14,858 1,914 5.10 16,308 1,971 5.11 14,340 1,912 5.12 13,015 1,873 5.13 16,030 2,062 5.14 14,735 1,912 5.15 12,377 1,797
As can be seen, 5.15 is, with regard to changesets merged, the quietest development cycle we have seen in the 5.x era. Indeed, one needs to go back to the 4.7 release in August 2016, which had 12,283 changesets from 1,582 developers, to find a quieter one. The relative slowness of this cycle is especially interesting considering that 5.15 will almost certainly be the next long-term support release. Kernel developers have often worried about vendors trying to shove unready code in for LTS releases, but there is little evidence of that happening here.
Instead, perhaps, the development community is just taking a well-deserved mid-pandemic break.
Individual contributors
Meanwhile, the number of developers participating in this release, while down from recent cycles, is higher than for some others in the 5.x era. Of the 1797 developers contributing to 5.15, 251 did so for the first time; that is a relatively low number but not out of line with previous releases. The most active developers in this cycle were:
Most active 5.15 developers
By changesets Christoph Hellwig 252 2.0% Namjae Jeon 171 1.4% Takashi Iwai 161 1.3% Vladimir Oltean 138 1.1% Colin Ian King 131 1.1% Arnd Bergmann 119 1.0% Andy Shevchenko 109 0.9% Thomas Zimmermann 108 0.9% Geert Uytterhoeven 100 0.8% Michael Straube 92 0.7% Linus Walleij 91 0.7% Krzysztof Kozlowski 91 0.7% Pavel Begunkov 83 0.7% Sean Christopherson 82 0.7% Thomas Gleixner 82 0.7% Dan Carpenter 80 0.6% Phillip Potter 79 0.6% Bart Van Assche 76 0.6% Randy Dunlap 73 0.6% Christophe JAILLET 73 0.6%
By changed lines Phillip Potter 137584 17.0% Namjae Jeon 42483 5.2% Konstantin Komarov 32228 4.0% Christoph Hellwig 22177 2.7% Jin Yao 16772 2.1% Hu Haowen 13102 1.6% Trevor Wu 12407 1.5% Linus Walleij 11863 1.5% Zack Rusin 11163 1.4% Lukas Bulwahn 9211 1.1% Konrad Dybcio 8728 1.1% Takashi Iwai 7994 1.0% Vladimir Oltean 7024 0.9% Arnd Bergmann 6965 0.9% Fabio Aiuto 6864 0.8% Kumar Kartikeya Dwivedi 5493 0.7% Quinn Tran 5319 0.7% James Smart 5287 0.7% Matthew Brost 5219 0.6% Iskren Chernev 5176 0.6%
Christoph Hellwig was the top contributor of changesets this time around; he continues his extensive refactoring of code in the block and SCSI subsystems, with occasional side trips to, for example, remove set_fs() from the m68k architecture. Namjae Jeon contributed the new ksmbd filesystem implementation, Takashi Iwai continued his work as the sound subsystem maintainer, Vladimir Oltean contributed a lot of network-driver improvements, and Colin Ian King did minor cleanups throughout the kernel tree.
The developer with the most changed lines this time around was Phillip Potter, who added the rt8818eu wireless network driver. Konstantin Komarov contributed the ntfs3 filesystem driver, and Jin Yao added perf events support for a number of newer Intel subarchitectures.
The kernel project depends on its testers and reviewers as much as it depends on its developers. For the 5.15 cycle, the developers with the most test and review credits were:
Test and review credits in 5.15
Tested-by Daniel Wheeler 62 8.2% Babu Moger 24 3.2% Dvora Fuxbrumer 21 2.8% Nathan Chancellor 13 1.7% Stefano Stabellini 13 1.7% Christophe Leroy 12 1.6% Will Deacon 12 1.6% Gerald Schaefer 12 1.6% Lukasz Majczak 12 1.6% Marc Zyngier 11 1.4% Michael Schmitz 10 1.3% Marek Vasut 10 1.3% Yi Zhang 10 1.3% Guenter Roeck 9 1.2% Michael Walle 9 1.2%
Reviewed-by Christoph Hellwig 211 3.9% Rob Herring 154 2.9% Darrick J. Wong 101 1.9% Laurent Pinchart 92 1.7% David Sterba 69 1.3% Hannes Reinecke 68 1.3% Hans de Goede 60 1.1% Daniel Vetter 59 1.1% Linus Walleij 56 1.0% Alex Deucher 53 1.0% Andy Shevchenko 52 1.0% Stephen Boyd 50 0.9% Lad Prabhakar 50 0.9% José Roberto de Souza 49 0.9% Christian König 48 0.9%
Many of the people who accrue test credits in the kernel tend not to be otherwise visible within our community. What we are seeing is tags applied during the internal review process at some companies; many companies have such processes, but they don't all document that work in the patch tags. A similar thing often happens with the review tags, but that is not the case this time around. The top reviewers take on a number of roles in the kernel project; remember that the most active reviewer this time around (Christoph Hellwig) was also the most active contributor of changesets.
Employers
Work on 5.15 was supported by 213 employers that we were able to identify. The most active employers were:
Most active 5.15 employers
By changesets Intel 1216 9.8% (Unknown) 958 7.7% 718 5.8% (None) 687 5.6% Red Hat 633 5.1% Linaro 577 4.7% SUSE 553 4.5% AMD 504 4.1% Huawei Technologies 465 3.8% NVIDIA 368 3.0% IBM 349 2.8% (Consultant) 306 2.5% 305 2.5% Canonical 275 2.2% NXP Semiconductors 264 2.1% Oracle 255 2.1% Renesas Electronics 236 1.9% Samsung 214 1.7% Arm 193 1.6% Linutronix 147 1.2%
By lines changed (None) 166216 20.5% Intel 79492 9.8% (Unknown) 50642 6.2% Samsung 46431 5.7% Linaro 35003 4.3% Paragon Software 32228 4.0% Red Hat 24395 3.0% (Consultant) 23610 2.9% AMD 22864 2.8% NVIDIA 21705 2.7% 20215 2.5% MediaTek 19706 2.4% SUSE 19547 2.4% 13960 1.7% VMWare 13518 1.7% SoMainline 11581 1.4% Huawei Technologies 11070 1.4% Renesas Electronics 10557 1.3% NXP Semiconductors 10443 1.3% Broadcom 10202 1.3%
As usual, there aren't many surprises here. Paragon Software, which has not been seen on these lists before, shows up as the result of the ntfs3 contribution. Another thing worthy of note is that Huawei contributed 465 changesets to 5.15 — a substantial contribution but also big decrease from the company's 1,731 changesets in 5.14. Had Huawei sustained the 5.14 level of activity, this development cycle would have been comparable to its predecessors in terms of changesets merged. That said, almost all of the companies listed above had lower levels of contribution to 5.15 compared to 5.14.
Code longevity
Finally, it can be interesting to look at how much code from each release has survived into the current kernel. This can be done with the brute-force technique of running git blame on each file in the kernel tree, then mapping the commit that created each line to the release in which it appeared. If one does this for the current Git history, the result looks like:
![[plot]](https://static.lwn.net/images/2021/lineplot-5.15.png)
The code added in most releases makes up less than 2% of the code that is found in the 5.15 kernel; 5.15 itself accounts for 2.1% of the total. At the beginning of the Git era, just before the 2.6.12 release in 2005, the kernel had about 10.8 million lines of code. Over 16 years later, about 2.3 million of those lines (just under a quarter) still exist in 5.15, making up about 7.2% of the total. If one actually looks, much of that code takes the form of individual lines reading "/*" and the like, but that is not all of it. There are, for example, still 72 files in the kernel tree that have never been changed since they were added as part of the initial commit in 2005.
As for the other releases that stand out in the plot, there is usually a fairly straightforward explanation. 4.12, for example, included one of many large dumps of amdgpu register definition header files; those tend to live forever and are, probably, read by nobody. The same is true of 5.3 and 5.9, among other releases. In other cases it is not so clear; 5.6 saw the addition of the ath11k network driver and the WireGuard VPN, but those are not enough to explain why so much code persists from that release.
How much of the new code from the 5.15 development cycle will remain in
coming years is yet to be seen. As the plot above shows, though, kernel
code has a certain longevity; much of it will be around until it is all
rewritten in Rust someday. Expect the development community to continue
adding and changing code at a high speed between now and then, though.
| Index entries for this article | |
|---|---|
| Kernel | Releases/5.15 |