|
|
Subscribe / Log in / New account

Some 4.20 development statistics

By Jonathan Corbet
December 21, 2018
This year's holiday gifts will include the 4.20 kernel; that can only mean that it is time for another look at where the code going into this release has come from. This development cycle was typically busy and brought a lot of new code into the kernel. There are some new faces showing up in the statistics this time around, but not a lot of surprises otherwise.

As of this writing, 13,856 non-merge changesets have found their way into the mainline repository for the 4.20 release; they were contributed by 1,743 developers. That makes 4.20 the busiest cycle since 4.15, but only by a little bit; both numbers are essentially in line with recent release history. Of those 1,743 developers, 283 were first-time contributors this time around. The most active 4.20 contributors were:

Most active 4.20 developers
By changesets
Lorenzo Bianconi1981.4%
Christoph Hellwig1451.0%
Laurent Pinchart1421.0%
Yue Haibing1411.0%
Paul E. McKenney1381.0%
Marcel Ziswiler1331.0%
Matthew Wilcox1290.9%
Rob Herring1260.9%
Colin Ian King1250.9%
Christian König1110.8%
Chris Wilson1100.8%
Hans Verkuil1090.8%
Trond Myklebust1020.7%
John Whitmore1010.7%
Andy Shevchenko970.7%
Nathan Chancellor910.7%
Kuninori Morimoto880.6%
Linus Walleij850.6%
Zhong Jiang840.6%
Michael Straube840.6%
By changed lines
Feifei Xu629658.2%
Spencer E. Olson342164.5%
Hannes Reinecke217002.8%
Guo Ren117131.5%
Ard Biesheuvel112271.5%
Matthew Wilcox104351.4%
Lorenzo Bianconi103421.4%
Anirudh Venkataramanan89861.2%
Evan Quan87851.1%
Sasha Neftin83931.1%
Horia Geantă80801.1%
David Howells80121.0%
Laurent Pinchart79641.0%
Jesse Brandeburg78821.0%
Sunil Goutham71810.9%
Boris Brezillon62110.8%
Hao Zheng58520.8%
Christoph Hellwig53260.7%
Hans Verkuil50840.7%
Greg Kroah-Hartman48290.6%

Lorenzo Bianconi reached the top of the "by changesets" column with a long set of changes to the mt76 network driver. Christoph Hellwig did a bunch of work in the block subsystem, as well as some significant improvements to the DMA mapping layer. Laurent Pinchart worked mostly with graphics drivers, Yue Haibing did a lot of cleanup work in various device drivers, and Paul McKenney worked mostly in the read-copy-update subsystem.

As is often the case, the "changed lines" column was dominated by changes to the AMD graphics drivers; Feifei Xu landed at the top with 15 patches adding more header files for those drivers. Spencer Olson made a bunch of improvements to the comedi drivers in the staging subsystem, Hannes Reinecke replaced the DAC960 driver with a reimplemented version, Guo Ren added the C-SKY architecture, and Ard Biesheuvel did a bunch of core work in the crypto subsystem, the jump label mechanism, and the Arm architecture.

Reviewing and testing patches are important parts of the development process. The most active reviewers and testers this time around were:

Test and review credits in 4.20
Tested-by
Andrew Bowers15513.9%
Jacopo Mondi383.4%
Stefan Wahren302.7%
Aaron Brown262.3%
Arnaldo Carvalho de Melo242.1%
Steve Longerbeam242.1%
Marcel Holtmann222.0%
Kees Cook181.6%
Mathieu Malaterre171.5%
Catalin Marinas161.4%
Niklas Cassel151.3%
Michael Schmitz151.3%
Mathieu Poirier151.3%
Sedat Dilek151.3%
Tony Brelinski151.3%
Tony Lindgren141.3%
Jarkko Nikula141.3%
Hiroyuki Yokoyama141.3%
Jeremy Linton131.2%
Farhan Ali131.2%
Reviewed-by
Rob Herring1903.7%
Alex Deucher1502.9%
Simon Horman1482.9%
Sebastian Reichel1092.1%
Christoph Hellwig1072.1%
Geert Uytterhoeven921.8%
Huang Rui911.8%
Andrew Morton751.5%
David Sterba741.4%
Chao Yu611.2%
Laurent Pinchart561.1%
Christian König541.1%
Biju Das501.0%
Junwei Zhang491.0%
Thomas Gleixner480.9%
Bjorn Andersson470.9%
Felix Kuehling460.9%
Nick Desaulniers460.9%
Fabrizio Castro460.9%
Johannes Thumshirn450.9%

Of the nearly 14,000 changes in 4.20, 953 (just under 7%) had Tested-by tags, while 4,198 (30%) had Reviewed-by tags.

Work on 4.20 was supported by 223 companies that we know of; the most active of those companies were:

Most active 4.20 employers
By changesets
Intel13289.6%
Red Hat11708.4%
(None)9626.9%
(Unknown)7645.5%
Linaro6474.7%
AMD6454.7%
IBM6274.5%
Huawei Technologies4943.6%
Google4843.5%
Renesas Electronics4493.2%
(Consultant)3702.7%
Mellanox3602.6%
SUSE3282.4%
Oracle2561.8%
ARM2541.8%
Bootlin2161.6%
Code Aurora Forum2041.5%
NXP Semiconductors1801.3%
Cisco1741.3%
Canonical1521.1%
By lines changed
AMD9401512.3%
Intel8499011.1%
(Unknown)579397.6%
Red Hat530106.9%
Code Aurora Forum304564.0%
(None)297973.9%
SUSE295733.9%
IBM287483.8%
Linaro284603.7%
Bootlin178242.3%
(Consultant)165572.2%
Marvell157812.1%
NXP Semiconductors138931.8%
MediaTek135991.8%
Mellanox135551.8%
Renesas Electronics134861.8%
Google126841.7%
Hangzhou C-SKY Microsystems117131.5%
Huawei Technologies110411.4%
Microsoft90201.2%

As usual, there are few surprises here; while many companies contribute to the kernel, the list of those doing the most work tends to be restricted to a fairly small number of them. It is worth noting that, of the 283 first-time contributors seen during this development cycle, 17 were working at Intel as of their first commit, while 13 were at the Code Aurora Forum, 12 at AMD, and 10 at Google. All told, over half of the first-time contributors were already affiliated with a company.

If one looks only at the 1,339 patches touching core kernel code (loosely defined as the contents of the fs, kernel, and mm directory trees), the results come out a bit different:

Most active core-kernel contributors
Developers
Paul E. McKenney1259.3%
Matthew Wilcox725.4%
Darrick J. Wong362.7%
Chao Yu342.5%
David Howells322.4%
Christoph Hellwig312.3%
Steve French282.1%
Trond Myklebust261.9%
Miklos Szeredi251.9%
Eric W. Biederman231.7%
Companies
Red Hat21816.3%
IBM14811.1%
SUSE1128.4%
Microsoft896.6%
Huawei Technologies735.5%
(Unknown)715.3%
Oracle695.2%
Linaro574.3%
Facebook413.1%
Google403.0%

There are a lot of companies that find it in their interest to support work on the Linux kernel, but rather fewer of them put resources into the core code that everybody uses.

Contributions all over the kernel tree are the fuel that keeps this project going, though. Once again, it would appear that, despite whatever problems the community may have, the kernel-development machine continues to run smoothly, integrating vast amounts of work into a new release every nine or ten weeks.

Index entries for this article
KernelReleases/4.20


to post comments

Some 4.20 development statistics

Posted Dec 22, 2018 4:37 UTC (Sat) by unixbhaskar (guest, #44758) [Link] (7 responses)

I can see M$FT at 3 rd place in terms of code contribution to the kernel. I think it is because Sasa and Matthew carrying the flag on behalf of M$FT??

Anyway, there were/are the contributor to the kernel but not at this rate or rank as high. Good for them I believe.

Some 4.20 development statistics

Posted Dec 23, 2018 1:49 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (4 responses)

M$FT is a rather silly way to refer to a company. Why do you use it?

Some 4.20 development statistics

Posted Dec 23, 2018 14:03 UTC (Sun) by lkundrak (subscriber, #43452) [Link] (1 responses)

Don't tell me you don't remember how and why has the company's full name became a swear word.

Some 4.20 development statistics

Posted Dec 23, 2018 16:49 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

> Don't tell me you don't remember how and why has the company's full name became a swear word.

I am aware of the history. It is still moniker to use today

Some 4.20 development statistics

Posted Dec 23, 2018 14:23 UTC (Sun) by unixbhaskar (guest, #44758) [Link] (1 responses)

This is really silly from your part to ask such a stupid question here. Please go figure. Look like you were/are living on a different planet...heck..

Enough

Posted Dec 23, 2018 15:03 UTC (Sun) by corbet (editor, #1) [Link]

OK please let's just stop this here. Time to go enjoy the holidays instead!

Some 4.20 development statistics

Posted Dec 23, 2018 3:59 UTC (Sun) by willy (subscriber, #9762) [Link] (1 responses)

I'm at Oracle now; I left MS in June.

Some 4.20 development statistics

Posted Dec 23, 2018 14:25 UTC (Sun) by unixbhaskar (guest, #44758) [Link]

Cool.Hope they are more deeply into this. :) Anyway, it shouldn't matter to ya Matthew...does it?

Some 4.20 development statistics

Posted Dec 22, 2018 14:51 UTC (Sat) by jhoblitt (subscriber, #77733) [Link] (5 responses)

It makes me a bit nervous that a single company (IBM) is now the source of > 25% of core changesets.

One company

Posted Dec 22, 2018 15:11 UTC (Sat) by corbet (editor, #1) [Link] (4 responses)

...note that IBM's prominence there is for the 4.20 cycle only; it would have arguably made a lot more sense to integrate over a year. For 4.20, this core contribution was dominated by Paul McKenney's RCU work.

If you look at roughly the last year (since 4.15), it comes out like this:

  1. Red Hat: 19%
  2. SUSE: 11%
  3. Oracle: 7%
  4. IBM: 6%
  5. Huawei: 5%
  6. Intel: 5%
  7. Google: 4%
  8. Facebook: 4%
  9. Microsoft: 4%
  10. (None): 3%

The table in the article was accurate but somewhat misleading; my apologies for that.

One company

Posted Dec 22, 2018 15:17 UTC (Sat) by jhoblitt (subscriber, #77733) [Link] (1 responses)

Over the longer period, IBM + RHT still come up to ~25% of changesets. I don't see this as a problem in and of itself but suspect the kernels vendor neutral reputation is critical for long term health of the project.

One company

Posted Dec 25, 2018 7:01 UTC (Tue) by drag (guest, #31333) [Link]

You keep a vendor neutral reputation by being vendor neutral. Not excluding contributors because they are being paid by a particular vendor is part of that. Whoever is capable of positively contributing to the kernel should be allowed to.

One company

Posted Dec 22, 2018 15:18 UTC (Sat) by madscientist (subscriber, #16861) [Link] (1 responses)

On the gripping hand, Red Hat's 19% plus IBM's 6% still gives 25% for IBM (here at the end of 2018), even if the entire year is considered...

One company

Posted Dec 24, 2018 19:40 UTC (Mon) by tonyblackwell (guest, #43641) [Link]

Ha! Are we all Moties then? An analogy of kernel development perhaps?

Some 4.20 development statistics

Posted Dec 29, 2018 6:33 UTC (Sat) by marcH (subscriber, #57642) [Link] (4 responses)

> Most active core-kernel contributors

Non-native speaker question: habits aside is there any English difference between "core" and "kernel"? I mean in computing (in every day English the latter seems more specific)

Some 4.20 development statistics - core kernel distinction

Posted Dec 29, 2018 11:12 UTC (Sat) by amacater (subscriber, #790) [Link] (3 responses)

I am a native English speaker but I parsed the sentence slightly differently. If you think of the code in the linux kernel as many subsystems: I think the distinction here is between "core kernel" - the stuff at the very heart, in the middle, at the centre of it all, that really matters to every system - as then described and "device drivers, peripheral code and other - potentially less important?? - stuff" around that. Think of the centre of the earth :)

If you're very old / working in specialist computing restoration / reading old books - "core" is an actual toroidal core per bit of memory. The Apollo 8 flight computers had physical core memory, for example.

Some 4.20 development statistics - core kernel distinction

Posted Dec 29, 2018 11:42 UTC (Sat) by marcH (subscriber, #57642) [Link] (2 responses)

I have some idea of what "core-kernel" means, sorry I should have explained better. What I'm wondering is whether the two English words mean the same thing as far as computing (not just Linux) is concerned, for instance whether "kernel-core" or "core-core" could be used instead and mean the exact same thing.

Some 4.20 development statistics - core kernel distinction

Posted Dec 29, 2018 12:38 UTC (Sat) by karkhaz (subscriber, #99844) [Link]

> "kernel-core" or "core-core" could be used instead and mean the exact same thing

These don't mean the same thing, and in fact don't make much sense without additional context. As you mentioned, 'kernel' has a specific meaning in computing, while 'core' is used more generically[1].

The phrase 'core-kernel' is short for 'core of the kernel', i.e. it implies possession: the kernel has a core. We already know what 'kernel' refers to (the Linux kernel), so it makes sense to refer to its core without further explanation. Applying the same reasoning to 'kernel-core'---which expands to 'kernel of the core'---the phrase becomes confusing, because 'core' is a less specific term than 'kernel' and it's not clear which core we are referring to. 'Core' can't be referring to the Linux Kernel (because otherwise we just would have said 'kernel' rather than 'core'), and it's not obvious what else it might refer to, since it's such a generic term.

Side note: If the phrase did not have a hyphen (i.e. "core kernel developers"), I would have parsed it as "core (kernel developers)" rather than "(core kernel) developers". Meaning 'those developers who are at the core of the kernel development community'.

[1] Except when it also has a specific meaning, e.g. in 'core dump'

Some 4.20 development statistics - core kernel distinction

Posted Dec 29, 2018 15:58 UTC (Sat) by gevaerts (subscriber, #21521) [Link]

I suspect there's a kernel of truth in your observation


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