Browse files

Merge with other repo

  • Loading branch information...
2 parents 7b28a52 + 2a05b8d commit 40e517efbf5de268fe72d16a5f7dd732346dba71 @gregkh committed Jun 1, 2012
Showing with 502 additions and 1 deletion.
  1. +3 −1 README
  2. +293 −0 maintainer.pin
  3. +206 −0 maintainer.txt
View
4 README
@@ -2,6 +2,9 @@ This is a repo containing a presentation about Linux kernel maintainers.
It's still under development, it's at the "rant" stage.
+Feel free to use the numbers in here in any presentations you wish to
+give, just properly attribute them please.
+
The presentation is licensed under the Creative Commons
"Attribution-Noncommercial-ShareAlike" license, version 3.0, that can be
found in detail at:
@@ -11,4 +14,3 @@ If you have any questions about the information in this presentation,
please feel free to contact me:
Greg Kroah-Hartman
greg@kroah.com
-
View
293 maintainer.pin
@@ -0,0 +1,293 @@
+#!/usr/bin/env pinpoint
+[font="Bitter" 70px]
+[top]
+[text-align=left]
+#[bg.jpg]
+[shading-opacity=0.000000]
+[black]
+
+- [top] [text-align=center][font=FifthLeg 190px]
+<b>
+<span size='xx-large' foreground='white'>Linux Kernel
+Maintainers</span>
+</b>
+<span font="Bitter" foreground='yellow' size='x-small'>Greg Kroah-Hartman</span>
+<span font="Bitter" size='x-small' foreground="yellow">gregkh@linuxfoundation.org</span>
+
+-- [white] [text-color=black]
+<span font="bitter" size="large" >
+2.831 developers
+ 320 companies</span>
+
+# number of developers for the past year
+# # of companies is the ones we know, there really are more.
+
+-- [white] [text-align=center] [text-color=black]
+<span font="Bitter">
+foo foo foo
+</span>
+
+# Speaker notes!!!!
+#
+# Given at the openSUSE conference, September 12 2011, Nuremberg Germany.
+
+-- [images/tw.jpg] [text-align=right] [top-right]
+
+# For those who don't know what a tumbleweed is.
+
+-- [white] [text-color=black]
+<span font="bitter" size="large" >
+Linux kernel statistics
+</span>
+
+# All stats are for the 2.6.36 - 3.0 kernels, the last year of development
+
+-- [white] [text-color=black]
+<span font="bitstream charter" size="large" >
+ 36.782 files
+14.647.033 lines
+</span>
+
+# still getting bigger
+#
+# Like the dots? Localization, know your audience.
+
+-- [white] [text-color=black]
+<span font="bitstream charter" size="large" >
+9.900 lines added
+6.800 lines removed
+2.200 lines changed
+</span>
+
+# rate of change per day
+# lots of churn
+
+-- [white] [text-color=black]
+<span font="bitstream charter" size="large" >
+5,8 changes per hour
+</span>
+
+# still going up, but slowing in the growth. 5.5 last year
+#
+# Change is proportional.
+
+
+-- [images/factory.jpg] [text-color=black]
+<span font="bitstream charter" size="xx-large"><b>Who is funding this work</b></span>
+<span font="bitstream charter" size="large"><b>
+1) 14.1%
+2) Red Hat 11.6%
+3) 8.2%
+4) Intel 6.6%
+5) SuSE 4.3%
+6) IBM 3.4%
+7) Texas Instruments 2.5%
+8) Nokia 2.0%
+9) Consultants 1.6%
+10) Broadcom 1.6%
+</b></span>
+
+# guess who #1 and #3 are
+#
+# No, not Microsoft, they were only #23
+#
+# And no, not Canonical, they were #36
+
+-- [images/factory.jpg] [text-color=black]
+<span font="bitstream charter" size="xx-large"><b>Who is funding this work</b></span>
+<span font="bitstream charter" size="large"><b>
+1) "Amateurs" 14.1%
+2) Red Hat 11.6%
+3) Unknown individuals 8.2%
+4) Intel 6.6%
+5) SuSE 4.3%
+6) IBM 3.4%
+7) Texas Instruments 2.5%
+8) Nokia 2.0%
+9) Consultants 1.6%
+10) Broadcom 1.6%
+</b></span>
+
+# Unknown are those we don't know, or those we know and they want to remain unknown.
+#
+# None are major contributors.
+#
+# Why contribute?
+# - paid to do so (or business model, Red Hat, SUSE)
+# - support their hardware (Intel, IBM, TI, Microsoft, etc.)
+# - they rely on Linux, so they contribute to ensure that it doesn't change in ways that would not benefit them (Nokia, Oracle, Google.)
+
+-- [white] [text-color=black]
+<span font="bitstream charter" size="xx-large">
+<b>Where is the roadmap?</b></span>
+
+# everyone wants a roadmap, they are wrong
+
+-- [images/ols_2006_keynote_08.jpg]
+
+# We make changes when they are needed, based on what people implement, not what marketing dreams up would be nice for the next version.
+#
+# We take the changes when they are done, and work.
+#
+# We support more devices, and more processors than any other operating system.
+#
+# We do stuff no operating system ever has.
+#
+# The only one to work on a different major platform from what it originally was designed, we scaled up and down (embedded and supercomputers.) No one has ever done that.
+
+-- [stretch] [images/ibm-background.jpg] [text-color=black] [text-align=left]
+<span font="bitstream charter" size="large"><b>
+“Linux is the only OS that will
+ run on architectures that haven’t
+ been invented yet”</b></span>
+<span font="bitstream charter"><b>
+ ― Dr. Irving Wladawsky-Berger
+</b></span>
+
+# Said this at LinuxCon 2011 in August in Vancouver.
+#
+# Was all about how IBM knows Linux is the future.
+
+-- [stretch] [images/heraclitus-background.png] [text-color=white] [top-right] [text-align=right]
+
+# Greek philosopher
+#
+# Need to embrace the change in order to survive.
+
+-- [stretch] [images/financial-background.png] [text-color=black] [text-align=left]
+<span font="bitstream charter" size="x-large"><b>“Linux took over Wall Street because
+ it moved faster than anyone else.”</b></span>
+<span font="bitstream charter"><b>
+ ― lots of financial CIOs
+</b></span>
+
+# lots of these companies roll their own.
+#
+# Etrade and NASDAQ run Gentoo to keep on the leading edge of stuff
+
+-- [white] [text-color=black] [text-align=left]
+<span font="bitstream charter" size="xx-large"><b>Enterprise distros</b></span>
+
+
+<span font="bitstream charter" size="large"><b>
+
+</b></span>
+
+# Not all companies want change, so Enterprise distros came about to try to sell Linux into those markets.
+#
+# They provide support and a slow moving system for companies that feel they don't like change.
+
+
+-- [white] [text-color=black] [text-align=left]
+<span font="bitstream charter" size="xx-large"><b>Enterprise distros</b></span>
+
+
+<span font="bitstream charter" size="large"><b>
+Duplicating Solaris release model?
+</b></span>
+
+# These distros are embracing the old model which has failed.
+#
+# My own opinion, not that of my employer, yada yada yada
+
+
+-- [white] [text-color=black] [text-align=left]
+<span font="bitstream charter" size="large"><b>
+“It is not necessary to change.
+ Survival is not mandatory.”</b></span>
+<span font="bitstream charter"><b>
+ ― W. Edwards Deming
+</b></span>
+
+# Deming helped Japan rebuild after WWII and taught product quality and production techniques using statistical methods.
+#
+# Brought this model back to the US to try to get companies there to adopt it when confronted with control problems.
+#
+# Companies that don't change, will fail, no one guarantees your business model will remain over time.
+
+
+-- [top] [text-align=center]
+<b>
+<span size='large' font="FifthLeg" foreground='green'>Tumbleweed
+</span>
+</b>
+
+# Let's discuss Tumbleweed, what it is, what it is not, and how it works
+#
+# "You are bringing Gentoo to openSUSE"
+
+--
+<span size='large' font="FifthLeg" foreground='green'>Tumbleweed is:</span>
+
+<span font="FifthLeg">openSUSE</span> with the latest stable packages
+
+# that's it. Quite simple :)
+
+--
+<span size='large' font="FifthLeg" foreground='green'>Tumbleweed is not:</span>
+
+a totally new distro
+
+# really, it isn't.
+
+--
+<span size='large' font="FifthLeg" foreground='green'>Tumbleweed is not:</span>
+
+a replacement for Factory
+
+# packages have to be in factory first, before they get into Tumbleweed.
+
+--
+<span size='large' font="FifthLeg" foreground='green'>Tumbleweed does not:</span>
+
+Replace <span font="FifthLeg">openSUSE</span> releases
+
+# is build on top of the most recent openSUSE release, it relies on this in order to work properly.
+
+--
+<span size='large' font="FifthLeg" foreground='green'>Using Tumbleweed:</span>
+
+Read wiki
+
+# Lots of good documentation, how to add the repo, one-click file, everything you ever wanted, and more.
+
+--
+<span size='large' font="FifthLeg" foreground='green'>Using Tumbleweed:</span>
+
+<tt>zypper dup</tt>
+
+# that's it, nothing complex, nothing fancy.
+#
+# If you do something else, it will break.
+
+--
+<b>No repo priorities</b>
+
+# breaks stuff, don't do it.
+
+--
+<b>How it all works</b>
+
+-- [white] [images/lifecycle-1.png]
+
+-- [white] [images/lifecycle-2.png]
+
+-- [white] [images/lifecycle-3.png]
+
+-- [white] [images/lifecycle-4.png]
+
+-- [white] [images/lifecycle-5.png]
+
+-- [white] [images/lifecycle-6.png]
+
+-- [white] [images/lifecycle-7.png]
+
+--
+<tt>https://github.com/gregkh/tumbleweed</tt>
+
+- [black][images/penguins.jpg][unscaled]
+
+# Everyone likes penguins
+
+#- [black] [font=Sans 100px]
+#ありがとう
View
206 maintainer.txt
@@ -0,0 +1,206 @@
+Kernel maintainers - what they do, want, etc...
+
+
+Last year, from the 3.0 to the 3.4 kernel release, the Linux kernel had we had
+2,833 developers from 373 different companies.
+
+For that year work of development, we went at 5.xx changes per hour, 24
+hours a day, 7 days a week.
+
+For just this last release, we applied patches at an average of 7.21 changes
+per hour, the fastest rate of change we have ever had.
+
+That's a huge rate of change, and this is just the number of patches we
+have applied, not all of the patches that are rejected. And if you have
+ever submitted a kernel patch, you know how hard it can be to get a patch
+accepted.
+
+Here's a picture of our development model, in a simplified form.
+
+We have about 3000 different developers. They make a patch, and send it
+through email to the file/driver maintainer. We have about 700 different
+maintainers listed in the kernel tree at the moment. That maintainer
+reviews it, and if they accept it, they forward it on to the subsystem
+maintainer. We have around 130 different subsystem maintainers at the
+moment.
+
+Those maintainers have public kernel trees that all get merged into the
+linux-next release every day. Then, when the merge window opens up, the
+subsystem maintainers send their stuff to Linus.
+
+I've been giving this talk, about how our model works, and how to get
+involved in the kernel development process for over 6 years now. What I've
+not talked about is how the people above the developers work. What they
+put up with, how they do their job, and what you can do to make their lives
+easier. So let's talk about that now.
+
+Linus quote:
+
+ Making fun of patches
+
+
+Now this is funny, but true. Really true. When you send a patch out to
+the world, you need to let go of your ego. Your code can be critiquied,
+dicussed, rejected, made fun of, and hopefully, accepted.
+
+But why the grumpyness? Maintainers are grumpy. I'm grumpy, and let me
+show you exactly why we are.
+
+I looked at the patches that I got in just the past 2 weeks, now this is
+during the middle of the merge window for the kernel, the time when no one
+should be sending me patches. Because of that, this probably shows a low
+number of patches, as the experienced kernel developers know to not send
+patches during this period. I also was out of the country, so a number of
+developers knew not to send me stuff.
+
+Even with all of those caviets, I got this many patches in 2 weeks to
+review:
+
+ 968 patches in 2 weeks
+
+Now the large majority of these patches are just fine, but still, I
+recieved all of the following problems:
+
+
+ Subject: [PATCH 48/48] ....
+ There was no 47 previous patches
+
+ 15 sequence patch series, with no indication which patch went in which order.
+
+ Patches 1,3-10, #2 never showed up
+
+ Patch with signed-off-by in the signature at the bottom of the patch
+
+ Patch with signature saying "Information in this email is confidential"
+
+ Patches with tabs converted to spaces
+
+ Patches with spaces converted to tabs
+
+ Patches with leading spaces deleted, everything else just fine.
+
+ Patches created with non-unified format
+
+ Patches created in the driver subdirectory, not at the root of the kernel directory
+
+ Patches created at /usr/src/linux-2.6.32/....
+
+ Patches that failed to apply
+
+ Patches that were made against a different subsystem's tree, without telling me
+
+ Patches that broke the build
+
+ Patches that broke the build on patch 3/6 and fixed it on patch 6/6
+
+ Patches that broke the build on patch 5/8 with a note saying a follow-on patch would fix it up
+
+ Patches that had nothing to do with me
+
+ 1 patch that was 145kb big (4500 lines added)
+
+ Patch with obvious wrong kerneldoc format that had never been tested
+
+Remember, this was a calm 2 weeks.
+
+Now, I'm not asking you to take pity on me, just realize that this is the
+level of incompitance that every single one of those 700 developers
+encounter on a consistant basis.
+
+So when you think we are acting grumpy, remember, how would you act if you
+had to deal with this all of the time?
+
+
+Let's get back to what the goal is here. You want to create a patch that
+is accepted as it does something that you want to do in Linux. The
+maintainer wants to reject it.
+
+Seriously. It's easier for the maintainer to not accept your code at all.
+To accept it, it takes time to review it, apply it, send it on up the
+development chain, handle any problems that might happen with the patch,
+accept responsibility for the patch, possibly fix any problems that happen
+later on when you disappear, and maintain it for the next 20 years.
+
+That's a lot of work that you are asking someone else to do on your behalf.
+You are asking someone who doesn't usually work for your company, who
+probably lives in a different country, who you have never met in person, to
+assume responsibility for your work, and to do extra work on top of the
+normal work they do in the kernel every day.
+
+So you can see how it's in my interest to ignore your patch. And it's in
+your interest to keep me from ignoring it, because you want it accepted.
+
+So your goal is, when sending a patch, is to give me NO excuse to not
+accept it. To make it such that if I ignore it, or reject it, I am the one
+that is the problem here, not you.
+
+What can you do to keep me from rejecting your patch outright.
+
+First off, don't do any of the things I listed above, that's obvious,
+right? But that's a "do not do" list, how about a list of what to do:
+
+ - proper coding style
+ - checkpatch.pl clean
+ - proper people and mailing lists cc:ed (get_maintainer.pl)
+ - proper subject
+ - small incremental change
+ - "obviously" correct
+ - good description of WHY the patch is needed
+ - tell me which tree it was made against if there is any question
+ - if multiple patches:
+ - tell me the ordering
+ - each patch needs to build properly and not break the build at any
+ step along the way
+ - make sure it applies, with no fuzz.
+ - make sure it builds
+ - make sure it works, if possible.
+
+
+If you do all of that, here's what I will do for you:
+ - respond to the patch in 1-2 weeks (longer if in middle of merge
+ window, or if at conferences.)
+ - offer constructuve criticism of the patch
+
+If this happens, don't ignore it. Don't wait 2 weeks to respond, as I will
+have forgotten what I wrote. Or, don't resend a patch that you think just
+fixed up all of the issues I wrote, without saying what you changed in the
+previous version.
+
+
+ - let the author know when the apply the patch, and where it can be found
+
+
+
+
+
+What the author should provide
+ - respond to feedback, don't ignore it
+ - don't submit and run away
+ -
+
+
+Why I guarantee to you:
+ - I will respond within a week, unless I am traveling or during the merge window
+ - I will email you when the patch goes into my trees, letting you know where it is at
+
+
+What I do:
+ - batch up subsystem patches
+ - pick a few, save in a mbox
+ - review them, if bad, let the author know why and how to fix it, if possible.
+ - edit the headers to fix up typos
+ - make sure they apply with 'patch -p1 --dry-run'
+ - apply to a branch, building after each patch is applied
+ - if all good, merge to my main branch, and send out emails that the patches are applied.
+
+
+All my scripts are public:
+ github /linux tree
+
+
+
+Linus quote "open source allows you to make fun of people"
+
+All the following are patches I got in the past 2 weeks:
+
+

0 comments on commit 40e517e

Please sign in to comment.