Who wrote 2.6.33
As of this writing, 10,500 non-merge commits have found their way into 2.6.33 - fairly normal by recent standards. These changes added almost 900,000 lines while deleting almost 520,000 others; as a result, the kernel grew by a mere 380,000 lines this time around. According to the most recent regression list, 97 regressions have been reported in 2.6.33, of which 20 remain unresolved.
Some 1,152 developers contributed code to 2.6.33. The most active of those were:
Most active 2.6.33 developers
By changesets Ben Hutchings 145 1.4% Frederic Weisbecker 145 1.4% Arnaldo Carvalho de Melo 138 1.3% Luis R. Rodriguez 130 1.2% Masami Hiramatsu 128 1.2% Bartlomiej Zolnierkiewicz 124 1.2% Eric Dumazet 108 1.0% Alan Cox 105 1.0% Manu Abraham 102 1.0% Thomas Gleixner 101 1.0% Eric W. Biederman 97 0.9% Roel Kluin 91 0.9% Alexander Duyck 88 0.8% Paul Mundt 87 0.8% Johannes Berg 80 0.8% Wey-Yi Guy 77 0.7% Alex Deucher 76 0.7% Jean Delvare 73 0.7% Al Viro 72 0.7%
By changed lines Bartlomiej Zolnierkiewicz 206468 18.1% Henk de Groot 50355 4.4% Jerry Chuang 49627 4.3% Ben Skeggs 37555 3.3% Philipp Reisner 23182 2.0% Eilon Greenstein 23123 2.0% Tomi Valkeinen 22508 2.0% Mike Frysinger 13116 1.1% Ben Hutchings 12680 1.1% Jakob Bornecrantz 11613 1.0% Wu Zhangjin 11325 1.0% Greg Kroah-Hartman 10468 0.9% Rajendra Nayak 9978 0.9% Manu Abraham 9625 0.8% jack wang 9171 0.8% Masami Hiramatsu 8973 0.8% Alan Cox 7672 0.7% David VomLehn 7331 0.6% Arnaldo Carvalho de Melo 7217 0.6%
While some of the usual names appear at the top of this list, there are some newcomers as well. Ben Hutchings did a lot of work with network drivers, including the addition of the SolarFlare SFC9000 driver (which has several co-authors). Frederic Weisbecker has been active in a number of areas, adding the hardware breakpoints code, removing the big kernel lock from the reiserfs filesystem, and working with tracing and the perf tool. Arnaldo Carvalho de Melo's work is almost all with the perf events subsystem and the perf tool in particular. Luis Rodriguez continues to work all over the wireless driver subsystem, and with the Atheros drivers in particular, and Masami Hiramatsu's largest contribution is the dynamic probing work.
In the "lines changed" column, Bartlomiej Zolnierkiewicz continues to work in fixing up some wireless drivers in the staging tree, deleting a lot of code in the process; he also continues his IDE driver work. Henk de Groot added the Agere driver for HERMES II chipsets, Jerry Chuang added the Realtek rtl8192u driver, and Ben Skeggs added much of the Nouveau driver.
Contributions to 2.6.33 came from 182 employers that your editor was able to identify. The most active of those are:
Most active 2.6.33 employers
By changesets (None) 1535 14.6% Red Hat 1223 11.6% Intel 1011 9.6% (Unknown) 868 8.3% IBM 500 4.8% Novell 390 3.7% Nokia 319 3.0% (Consultant) 316 3.0% Fujitsu 204 1.9% Texas Instruments 199 1.9% Atheros Communications 169 1.6% (Academia) 166 1.6% AMD 165 1.6% Oracle 136 1.3% Analog Devices 130 1.2% Renesas Technology 126 1.2% Pengutronix 125 1.2% HP 124 1.2% Solarflare Communications 123 1.2%
By lines changed (None) 304895 26.7% (Unknown) 109716 9.6% Red Hat 92991 8.1% Broadcom 54272 4.8% Realtek 49951 4.4% Intel 46302 4.1% Nokia 37505 3.3% Novell 27235 2.4% IBM 26783 2.3% (Consultant) 25845 2.3% Texas Instruments 24232 2.1% LINBIT 23247 2.0% Analog Devices 19677 1.7% VMWare 16045 1.4% Samsung 15707 1.4% Solarflare Communications 15054 1.3% JiangSu Lemote Corp. 11439 1.0% AMD 9218 0.8% Universal Scientific Industrial Co. 9194 0.8%
As usual, Red Hat maintains its position at the top of the list, but others are gaining; we may yet see a day when Red Hat is just one of several major contributors. Some readers may be surprised to see Broadcom near the top of the list, given that this company's reputation for contribution is not the best. The truth of the matter is that Broadcom has several developers contributing to various drivers in the networking and SCSI subsystems; it's only in the wireless realm that the trouble starts.
For the fun of it, your editor typed the "changeset percent" numbers for the last ten releases into a spreadsheet and got this plot:
The percentages are surprisingly stable over the course of almost three years. The most obviously identifiable trends, perhaps, are the steady increases in the contributions from Intel and Nokia.
All told, the process continues to function smoothly. The occasional complaint about certain companies not fully participating in the process notwithstanding, the picture is one of hundreds of companies cooperating to a high degree to create the Linux kernel despite their fierce competition elsewhere. The significant percentage of code coming from developers working on their own time shows that Linux is not just a corporate phenomenon, though. We have built a development community which is able to incorporate the interests and work of an astonishingly wide variety of people into a single kernel.
As always, thanks are due to Greg Kroah-Hartman, who has done a great deal of work to reduce the size of the "(Unknown)" entries in the tables above.
Index entries for this article | |
---|---|
Kernel | Releases/2.6.33 |
Posted Feb 11, 2010 6:27 UTC (Thu)
by dlang (guest, #313)
[Link] (6 responses)
Posted Feb 11, 2010 12:35 UTC (Thu)
by bmr (subscriber, #33167)
[Link] (5 responses)
Posted Feb 11, 2010 15:20 UTC (Thu)
by corbet (editor, #1)
[Link] (4 responses)
Posted Feb 12, 2010 0:21 UTC (Fri)
by nevets (subscriber, #11875)
[Link] (3 responses)
Even though, I started as that type of work with Linux, today I bet a lot of it is professors using Linux as a learning tool and then those students get hooked on working on the kernel. It's not that they are not paid to do it, it may more likely be that they are not yet paid to do it.
I believe that Frederic Weisbecker falls under this category.
Posted Feb 12, 2010 2:04 UTC (Fri)
by eparis123 (guest, #59739)
[Link] (2 responses)
It's not that they are not paid to do it, it may more likely be that
they are not yet paid to do it. I've personally been in this category and been contacted by Greg, where I
replied being in the 'enthusiast' group. Yes, I'm a college student, but I
did all my patches without any outside influence. How come you want to consider this as 'paid' work?
Posted Feb 12, 2010 3:06 UTC (Fri)
by nevets (subscriber, #11875)
[Link] (1 responses)
I'm actually quite happy to see that number so high, for the same reason I used the word "yet". Because I know with such a large knowledge base coming up, there will be no limit to how far Linux will go. This "(None)" group will soon be in the paid to do Linux group, and hopefully there will be more inspiring new engineers joining that "(None)" group where it will always be at the top.
Posted Feb 17, 2010 20:45 UTC (Wed)
by nlucas (guest, #33793)
[Link]
I don't consider that as paid kernel work, just a one time contribution by
I'm sure there are lots of people like me in that situation.
Posted Feb 11, 2010 8:20 UTC (Thu)
by vblum (guest, #1151)
[Link]
Posted Feb 11, 2010 10:44 UTC (Thu)
by hppnq (guest, #14462)
[Link] (5 responses)
It is not at all at the top of the list. Maybe you mean "at the top of the list where we discard the four times bigger contribution[*] of people who can't be identified as associated with a particular company".
[*] Actual lines of kernel code changed.
Posted Feb 11, 2010 20:45 UTC (Thu)
by dlang (guest, #313)
[Link]
"Unknown" is the people who can't be identified as associated with a particular company.
Posted Feb 16, 2010 23:30 UTC (Tue)
by roelofs (guest, #2599)
[Link] (3 responses)
[*] Actual lines of kernel code changed.
Er...did we overlook the title of the graph? Specifically the "changesets" and "company" parts? ;-)
(Also see the upstream clarification about what "(None)" means.)
Greg
Posted Feb 17, 2010 11:22 UTC (Wed)
by hppnq (guest, #14462)
[Link] (2 responses)
In the graph the large contribution that cannot be attributed to specific company-sponsored efforts is indeed completely discarded, when compared to the list, where the two categories "None" and "Unknown" are at the top of the list (I mentioned lines of code changed).
I observed that "number three in the list" is not "top of the list", especially since the article recognizes the "None" contribution as "significant".
Posted Feb 18, 2010 19:19 UTC (Thu)
by efexis (guest, #26355)
[Link] (1 responses)
Posted Feb 19, 2010 8:07 UTC (Fri)
by hppnq (guest, #14462)
[Link]
If you insist on leaving the academic trail and you want to play word games: see the title of the bloody article. Consider taking those courses. Skip set theory.
If you were joking -- and I honestly hope you are -- I had a good laugh! Especially the "above the list" was a brilliant trouvaille.
Posted Feb 11, 2010 17:10 UTC (Thu)
by proski (subscriber, #104)
[Link] (1 responses)
Posted Feb 12, 2010 2:07 UTC (Fri)
by eparis123 (guest, #59739)
[Link]
Posted Feb 11, 2010 20:11 UTC (Thu)
by daney (guest, #24551)
[Link] (2 responses)
Posted Feb 11, 2010 20:44 UTC (Thu)
by dlang (guest, #313)
[Link] (1 responses)
there's not a link in this article to the analysis scripts, but I think they've had one in past articles (Corbett, would it make sense to try and include a link to the scripts in all the articles?)
Posted Feb 12, 2010 11:58 UTC (Fri)
by patrick_g (subscriber, #44470)
[Link]
Posted Feb 12, 2010 8:25 UTC (Fri)
by atl (guest, #5255)
[Link] (3 responses)
The truth of the matter is that Broadcom has several developers contributing to various drivers in the networking and SCSI subsystems; it's only in the wireless realm that the trouble starts. Not really :( Their MIPS SOC solutions for stbs are completely missing from the main kernel, which is very annoying when you are stuck with 2.6.12 "vendor" kernel and no way to move forward.
Posted Feb 13, 2010 18:47 UTC (Sat)
by mb (subscriber, #50428)
[Link] (1 responses)
Which arch are you talking about? BCM63xx?
Posted Feb 15, 2010 10:14 UTC (Mon)
by atl (guest, #5255)
[Link]
ls linux-2.6.12-brcm-4.2/arch/mips/brcmstb
Kconfig brcm93563 brcm97038c0 brcm97112 brcm97312 brcm97315bbx brcm97319 brcm97328 brcm97400b0 brcm97401c0 brcm97403a0 brcm97455 common
The patch to 2.6.12 can be downloaded here:
The sad part is that all this is accompanied by 40k binary driver that only have couple of ioctl so it doesn't really need to be binary but because of this crap I can't really port their stuff to something more recent.
Posted Feb 15, 2010 19:18 UTC (Mon)
by dion (guest, #2764)
[Link]
It's absolutely incredible that Atheros and Broadcom feel that it's ok for them to profit from Linux support for their chips, yet they insist on NDAs and refusing to do anything to document their chips.
Someone with a vicious lawyer ought to educate Atheros about the GPL in a way that reminds them that a lot (most?) of their SoCs are sold to people who like to put Linux on them and proper Linux support only helps them sell more chips.
What could Atheros or Broadcom possibly hope to gain from keeping their datasheets secret?
Posted Feb 18, 2010 7:12 UTC (Thu)
by DYN_DaTa (guest, #34072)
[Link] (3 responses)
Posted Feb 18, 2010 9:27 UTC (Thu)
by mangoo (guest, #32602)
[Link] (1 responses)
Posted Feb 19, 2010 1:57 UTC (Fri)
by xoddam (subscriber, #2322)
[Link]
I use Ubuntu on the desktop and CentOS on the server, mostly. But my economic activity (via my employer and hosting providers) pays real money to RedHat, whereas I never gave a penny to Canonical or the tiny-but-heroic CentOS team.
Free software is an ecosystem, not a mere labour exchange.
Posted Feb 18, 2010 21:48 UTC (Thu)
by bzolnier (guest, #28067)
[Link]
Would it be possible to get a similar graph for "Signoffs contributed by company"?
Who wrote 2.6.33
Who wrote 2.6.33
The "None" figure is people who are known to be working on their own time - they have told us so. Those we don't know about are the "Unknown" number instead.
"(None)"
How many are college students? When people think of working on their own time, you can imagine an engineer that is doing one job during the day and hacking on Linux at night.
"(None)"
"(None)"
"(None)"
"(None)"
regression on a driver. Although I've done it as a paid worker, the kernel
is not what I work with. Just come across that bug when trying to understand
why a piece of hardware we use stopped working.
sheer luck.
Who wrote 2.6.33
Who wrote 2.6.33
As usual, Red Hat maintains its position at the top of the list
Who wrote 2.6.33
It is not at all at the top of the list. Maybe you mean "at the top of the list where we discard the four times bigger contribution[*] of people who can't be identified as associated with a particular company".
Who wrote 2.6.33
Who wrote 2.6.33
Er...did we overlook the title of the graph? Specifically the "changesets" and "company" parts? ;-)
(Also see the upstream clarification about what "(None)" means.)
"where the two categories "None" and "Unknown" are at the top of the list"Who wrote 2.6.33
Out of context, they yes do look to be at the top of the list. Within context, however, the collection referred to as '(none)' is merely above the list, for purpose of completeness if nothing else, as the list that is being discussed is as the title says: "Most active 2.6.33 employers"... as '(none)' isn't an employer, it can't be top of the list of active employers, which means that RedHat is at the top. By definition.
As with '(unknown)', it's highly unlikely that all the changes under '(unknown)' are from a single employer, so it's unlikely that from that collection there is going to be someone who can top RedHat in the list.
"I observed that "number three in the list" is not "top of the list""
Nup, you observed that you can be top of one set without being top of all sets :-)
If what you are thinking is that one should take the "None" and "Unknown" categories out of the list titled "Most active employers", because we are only considering positively identified company contributions to the Linux kernel, then let's skip the step where I recommend basic courses in English, logic and statistics and just conclude that that's the scenario I was pointing out in my original comment.
Who wrote 2.6.33
The bugfixes that go into late release candidates may be small in size, but they are sometimes big in impact. Some of those fixes require a lot of work and patience.
It's too early to count
It's too early to count
a single line of change can be the result of days of frustration.
Who wrote 2.6.33
Who wrote 2.6.33
Who wrote 2.6.33
The numbers are a little bit differents. I don't know why.
Who wrote 2.6.33
Who wrote 2.6.33
Broadcom stuff
brcm93560 brcm97038 brcm97110 brcm97115 brcm97314 brcm97317 brcm97320 brcm97329 brcm97401a0 brcm97402b0s brcm97440a0 brcm97456 lib
brcm93560b0 brcm97038b0 brcm97111 brcm97118a0 brcm97315 brcm97318 brcm97327 brcm97400a0 brcm97401b0 brcm97402s brcm97440b0 brcm97456b0
http://hdtvbg.com/foss/linux-stb-4.2.patch.gz
Atheros are just as stupid
Who wrote 2.6.33
Who wrote 2.6.33
So RedHat's customers subsidise Ubuntu -- how is this a bad thing?
Who wrote 2.6.33