├── LICENSE
├── README
├── images
├── patches_per_hour.png
└── penguins.jpg
├── linaro.txt
├── maintainer.odp
├── maintainer.pdf
├── maintainer.pin
├── maintainer.txt
├── notes
├── show_presentation.sh
└── template
├── lf_template.odp
├── lf_template_1.svg
└── lf_template_2.svg
/LICENSE:
--------------------------------------------------------------------------------
1 | The presentation is licensed under the Creative Commons
2 | "Attribution-Noncommercial-ShareAlike" license, version 4.0, that can be
3 | found in detail at:
4 | http://creativecommons.org/licenses/by-nc-sa/4.0/
5 |
--------------------------------------------------------------------------------
/README:
--------------------------------------------------------------------------------
1 | This is a repo containing a presentation about Linux kernel maintainers.
2 |
3 | It's still under development, it's at the "rant" stage.
4 |
5 | Feel free to use the numbers in here in any presentations you wish to
6 | give, just properly attribute them please.
7 |
8 | The presentation is licensed under the Creative Commons
9 | "Attribution-Noncommercial-ShareAlike" license, version 4.0, that can be
10 | found in detail at:
11 | http://creativecommons.org/licenses/by-nc-sa/4.0/
12 |
13 | If you have any questions about the information in this presentation,
14 | please feel free to contact me:
15 | Greg Kroah-Hartman
16 | greg@kroah.com
17 |
--------------------------------------------------------------------------------
/images/patches_per_hour.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/gregkh/presentation-linux-maintainer/32a5867f2f1bdeececf9ebd674fbd21493f89c90/images/patches_per_hour.png
--------------------------------------------------------------------------------
/images/penguins.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/gregkh/presentation-linux-maintainer/32a5867f2f1bdeececf9ebd674fbd21493f89c90/images/penguins.jpg
--------------------------------------------------------------------------------
/linaro.txt:
--------------------------------------------------------------------------------
1 | Why I don't want your code
2 |
3 | or
4 | Linux Kernel maintainers, why are they so grumpy?
5 |
6 | Here's the Linux kernel development process.
7 |
8 | Patches flow from developers through maintainers, up to subsystem
9 | maintainers, then to Linus for a release.
10 |
11 | This is well known, and we have a lot of people contributing to Linux:
12 | big numbers go here
13 |
14 | but what is a maintainer?
15 |
16 | Maintainers are like editors in the publishing industry. They work with
17 | developers to review, edit, suggest, reject, and accept their patches.
18 | Every once in a while, maintainers get to go back to doing what they
19 | love to do, i.e. be a developer.
20 |
21 | So, usually, if you waste a maintainer's time, you make them upset as
22 | they could be doing more productive things, like new development of
23 | their own, or accepting patches from other people that aren't wasting
24 | their time.
25 |
26 | How do you waste a maintainer's time?
27 |
28 | - don't follow the documented submitsion process
29 |
30 | Here's a list of some of the things that people sent me, in a span of
31 | two weeks, that were wrong and they should have never sent:
32 | - patch [48/48] where there were no 47 other patches
33 | - 15 patches in a series with no order given
34 | - patch 1, 3-10, number 2 never showed up
35 | ..... (steal from other talk)
36 |
37 |
38 | List of things from one Linaro developer sent me over the past month:
39 | - 10 patch series with one sentance description for the whole series, saying what it did, but no idea why it is needed.
40 | - half of the patches didn't even build
41 | -
42 | - second round of 10 patch series with no description as to what changed
43 | - random patches sent that replaced individual patches in this series, with no numbering as to which one it was
44 | - third resend of patches without any ordering specified
45 | - fourth resend of patches, described as second version.
46 | - insisted that two of these patches HAD to be applied for 3.9-rc1
47 | - I applied them based on someone's comments I trusted.
48 | - required follow-on patch to actually work properly
49 | - subsystem maintainer returned from vacation, noticed the patches did not
50 | work at all, I had to revert all 3 1 day before 3.9-rc1 merge window opened up.
51 |
52 | - End result, I will not accept patches from this developer at all.
53 |
54 | -
55 |
56 |
57 | These were obvious things.
58 |
59 | It is in my self-interest to ignore your patch
60 |
61 | So, what to do about this:
62 |
63 | give me no excuse to reject your patch
64 | ... steal from other talk...
65 |
66 |
67 |
68 |
69 |
--------------------------------------------------------------------------------
/maintainer.odp:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/gregkh/presentation-linux-maintainer/32a5867f2f1bdeececf9ebd674fbd21493f89c90/maintainer.odp
--------------------------------------------------------------------------------
/maintainer.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/gregkh/presentation-linux-maintainer/32a5867f2f1bdeececf9ebd674fbd21493f89c90/maintainer.pdf
--------------------------------------------------------------------------------
/maintainer.pin:
--------------------------------------------------------------------------------
1 | #!/usr/bin/env pinpoint
2 | [font="Bitter" 70px]
3 | [top]
4 | [text-align=left]
5 | #[bg.jpg]
6 | [shading-opacity=0.000000]
7 | [black]
8 |
9 | - [top] [text-align=center][font=FifthLeg 190px]
10 |
11 | Linux Kernel
12 | Maintainers
13 |
14 | Greg Kroah-Hartman
15 | gregkh@linuxfoundation.org
16 |
17 | -- [white] [text-color=black]
18 |
19 | 2.831 developers
20 | 320 companies
21 |
22 | # number of developers for the past year
23 | # # of companies is the ones we know, there really are more.
24 |
25 | -- [white] [text-align=center] [text-color=black]
26 |
27 | foo foo foo
28 |
29 |
30 | # Speaker notes!!!!
31 | #
32 | # Given at the openSUSE conference, September 12 2011, Nuremberg Germany.
33 |
34 | -- [images/tw.jpg] [text-align=right] [top-right]
35 |
36 | # For those who don't know what a tumbleweed is.
37 |
38 | -- [white] [text-color=black]
39 |
40 | Linux kernel statistics
41 |
42 |
43 | # All stats are for the 2.6.36 - 3.0 kernels, the last year of development
44 |
45 | -- [white] [text-color=black]
46 |
47 | 36.782 files
48 | 14.647.033 lines
49 |
50 |
51 | # still getting bigger
52 | #
53 | # Like the dots? Localization, know your audience.
54 |
55 | -- [white] [text-color=black]
56 |
57 | 9.900 lines added
58 | 6.800 lines removed
59 | 2.200 lines changed
60 |
61 |
62 | # rate of change per day
63 | # lots of churn
64 |
65 | -- [white] [text-color=black]
66 |
67 | 5,8 changes per hour
68 |
69 |
70 | # still going up, but slowing in the growth. 5.5 last year
71 | #
72 | # Change is proportional.
73 |
74 |
75 | -- [images/factory.jpg] [text-color=black]
76 | Who is funding this work
77 |
78 | 1) 14.1%
79 | 2) Red Hat 11.6%
80 | 3) 8.2%
81 | 4) Intel 6.6%
82 | 5) SuSE 4.3%
83 | 6) IBM 3.4%
84 | 7) Texas Instruments 2.5%
85 | 8) Nokia 2.0%
86 | 9) Consultants 1.6%
87 | 10) Broadcom 1.6%
88 |
89 |
90 | # guess who #1 and #3 are
91 | #
92 | # No, not Microsoft, they were only #23
93 | #
94 | # And no, not Canonical, they were #36
95 |
96 | -- [images/factory.jpg] [text-color=black]
97 | Who is funding this work
98 |
99 | 1) "Amateurs" 14.1%
100 | 2) Red Hat 11.6%
101 | 3) Unknown individuals 8.2%
102 | 4) Intel 6.6%
103 | 5) SuSE 4.3%
104 | 6) IBM 3.4%
105 | 7) Texas Instruments 2.5%
106 | 8) Nokia 2.0%
107 | 9) Consultants 1.6%
108 | 10) Broadcom 1.6%
109 |
110 |
111 | # Unknown are those we don't know, or those we know and they want to remain unknown.
112 | #
113 | # None are major contributors.
114 | #
115 | # Why contribute?
116 | # - paid to do so (or business model, Red Hat, SUSE)
117 | # - support their hardware (Intel, IBM, TI, Microsoft, etc.)
118 | # - they rely on Linux, so they contribute to ensure that it doesn't change in ways that would not benefit them (Nokia, Oracle, Google.)
119 |
120 | -- [white] [text-color=black]
121 |
122 | Where is the roadmap?
123 |
124 | # everyone wants a roadmap, they are wrong
125 |
126 | -- [images/ols_2006_keynote_08.jpg]
127 |
128 | # We make changes when they are needed, based on what people implement, not what marketing dreams up would be nice for the next version.
129 | #
130 | # We take the changes when they are done, and work.
131 | #
132 | # We support more devices, and more processors than any other operating system.
133 | #
134 | # We do stuff no operating system ever has.
135 | #
136 | # 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.
137 |
138 | -- [stretch] [images/ibm-background.jpg] [text-color=black] [text-align=left]
139 |
140 | “Linux is the only OS that will
141 | run on architectures that haven’t
142 | been invented yet”
143 |
144 | ― Dr. Irving Wladawsky-Berger
145 |
146 |
147 | # Said this at LinuxCon 2011 in August in Vancouver.
148 | #
149 | # Was all about how IBM knows Linux is the future.
150 |
151 | -- [stretch] [images/heraclitus-background.png] [text-color=white] [top-right] [text-align=right]
152 |
153 | # Greek philosopher
154 | #
155 | # Need to embrace the change in order to survive.
156 |
157 | -- [stretch] [images/financial-background.png] [text-color=black] [text-align=left]
158 | “Linux took over Wall Street because
159 | it moved faster than anyone else.”
160 |
161 | ― lots of financial CIOs
162 |
163 |
164 | # lots of these companies roll their own.
165 | #
166 | # Etrade and NASDAQ run Gentoo to keep on the leading edge of stuff
167 |
168 | -- [white] [text-color=black] [text-align=left]
169 | Enterprise distros
170 |
171 |
172 |
173 |
174 |
175 |
176 | # Not all companies want change, so Enterprise distros came about to try to sell Linux into those markets.
177 | #
178 | # They provide support and a slow moving system for companies that feel they don't like change.
179 |
180 |
181 | -- [white] [text-color=black] [text-align=left]
182 | Enterprise distros
183 |
184 |
185 |
186 | Duplicating Solaris release model?
187 |
188 |
189 | # These distros are embracing the old model which has failed.
190 | #
191 | # My own opinion, not that of my employer, yada yada yada
192 |
193 |
194 | -- [white] [text-color=black] [text-align=left]
195 |
196 | “It is not necessary to change.
197 | Survival is not mandatory.”
198 |
199 | ― W. Edwards Deming
200 |
201 |
202 | # Deming helped Japan rebuild after WWII and taught product quality and production techniques using statistical methods.
203 | #
204 | # Brought this model back to the US to try to get companies there to adopt it when confronted with control problems.
205 | #
206 | # Companies that don't change, will fail, no one guarantees your business model will remain over time.
207 |
208 |
209 | -- [top] [text-align=center]
210 |
211 | Tumbleweed
212 |
213 |
214 |
215 | # Let's discuss Tumbleweed, what it is, what it is not, and how it works
216 | #
217 | # "You are bringing Gentoo to openSUSE"
218 |
219 | --
220 | Tumbleweed is:
221 |
222 | openSUSE with the latest stable packages
223 |
224 | # that's it. Quite simple :)
225 |
226 | --
227 | Tumbleweed is not:
228 |
229 | a totally new distro
230 |
231 | # really, it isn't.
232 |
233 | --
234 | Tumbleweed is not:
235 |
236 | a replacement for Factory
237 |
238 | # packages have to be in factory first, before they get into Tumbleweed.
239 |
240 | --
241 | Tumbleweed does not:
242 |
243 | Replace openSUSE releases
244 |
245 | # is build on top of the most recent openSUSE release, it relies on this in order to work properly.
246 |
247 | --
248 | Using Tumbleweed:
249 |
250 | Read wiki
251 |
252 | # Lots of good documentation, how to add the repo, one-click file, everything you ever wanted, and more.
253 |
254 | --
255 | Using Tumbleweed:
256 |
257 | zypper dup
258 |
259 | # that's it, nothing complex, nothing fancy.
260 | #
261 | # If you do something else, it will break.
262 |
263 | --
264 | No repo priorities
265 |
266 | # breaks stuff, don't do it.
267 |
268 | --
269 | How it all works
270 |
271 | -- [white] [images/lifecycle-1.png]
272 |
273 | -- [white] [images/lifecycle-2.png]
274 |
275 | -- [white] [images/lifecycle-3.png]
276 |
277 | -- [white] [images/lifecycle-4.png]
278 |
279 | -- [white] [images/lifecycle-5.png]
280 |
281 | -- [white] [images/lifecycle-6.png]
282 |
283 | -- [white] [images/lifecycle-7.png]
284 |
285 | --
286 | https://github.com/gregkh/tumbleweed
287 |
288 | - [black][images/penguins.jpg][unscaled]
289 |
290 | # Everyone likes penguins
291 |
292 | #- [black] [font=Sans 100px]
293 | #ありがとう
294 |
--------------------------------------------------------------------------------
/maintainer.txt:
--------------------------------------------------------------------------------
1 | Linux Kernel maintainers
2 |
3 | When I first started writing this talk, it quickly turned into one big long
4 | rant. I ended up listing all of the different problems that I had with
5 | patches that people had sent me over the past few years.
6 |
7 | While this would have been a very fun and cathartic talk for me, I figured
8 | that you all just watching me complain for 30 minutes wouldn't be the most
9 | entertaining thing, so I figured I would try to tone it down.
10 |
11 | ----------
12 |
13 | So, let's talk about the main problem that people seem to have with Linux
14 | kernel maintainers, why are they so grumpy? Hopefully by the end of this
15 | talk, you will have an idea of why this always happens, and what you can do
16 | to avoid having that anger be directed at you.
17 |
18 | Also, I'm going to cover what you should expect from a good kernel
19 | maintainer, so if you are a maintainer, here's something that developers
20 | can use to get back at you, and me, as I figure it's only fair.
21 |
22 | I am going to complain a lot in this talk. Please don't get the impression
23 | that I don't like doing this type of work. I love it. It's the best job
24 | in the world that I've ever had, and I can't think of anything that I would
25 | rather be doing.
26 |
27 |
28 | ---------
29 |
30 | 2,833 developers
31 | 373 companies
32 |
33 |
34 | This makes the Linux kernel the largest contributed body of software
35 | that has ever been created.
36 |
37 | This is also the number of companies that we know about. There are more
38 | that we do not know of at the moment, as I haven't been keeping up to
39 | date with tracking some of these numbers over the past 2 kernel
40 | releases. So the number really is a bit bigger than this.
41 |
42 | ---------
43 |
44 | 5.79 changes per hour
45 |
46 | For that year of development, we went at this rate, 24 hours a day, 7 days
47 | a week. This is up from last year, which was at 5.2 or so, so we are
48 | increasing, which is scary, right?
49 |
50 | ---------
51 |
52 | 7.21 changes per hour
53 |
54 | 3.4.0 release
55 |
56 | This past 3.4 release was the fastest we have ever created. That number
57 | shows just how well the Linux kernel development model is working. We are
58 | growing in developers and in how fast we are developing overall.
59 |
60 | Now this is just the patches we accepted, not all of the patches that have
61 | been submitted, lots of patches are rejected, as anyone who has ever tried
62 | to submit a patch can attest to.
63 |
64 | ---------
65 |
66 | [Development model picture]
67 |
68 | Here's a picture of our development model, in a simplified form.
69 |
70 | We have about 3000 different developers. They make a patch, and send it
71 | through email to the file/driver maintainer. We have about 700 different
72 | maintainers listed in the kernel tree at the moment. That maintainer
73 | reviews it, and if they accept it, they forward it on to the subsystem
74 | maintainer. We have around 130 different subsystem maintainers at the
75 | moment.
76 |
77 | Those maintainers have public kernel trees that all get merged into the
78 | linux-next release every day. Then, when the merge window opens up, the
79 | subsystem maintainers send their stuff to Linus.
80 |
81 | ---------
82 |
83 | Patches I received in the past 2 weeks
84 |
85 | So, let's look at one of these subsystem maintainers. I maintain the USB,
86 | driver core, tty, staging, and a few other various parts of the Linux
87 | kernel.
88 |
89 | These past 2 weeks is the timeframe when we had our big merge window, when
90 | all of the subsystem maintainers sent patches off to Linus. During this
91 | time frame, no core kernel developer sends new stuff to subsystem
92 | maintainers, as they know they are busy, and nothing that gets sent can
93 | really be looked at until after the merge window closes.
94 |
95 | So, almost all of the patches I got in the past 2 weeks were not from
96 | developers that do a whole lot of kernel work, nor were the, for the most
97 | part, large patches with new things being proposed for the kernel.
98 |
99 | ---------
100 |
101 | Patches I received in the past 2 weeks
102 |
103 | 487
104 |
105 | Yeah, that's the number of patches I got during the "slow" period of the
106 | kernel development cycle. This does not include the number of messages
107 | around those patches as other developers commented on them, or other
108 | various things about those patches (like "have you applied my patch yet?"
109 | messages.)
110 |
111 | Now the large majority of these patches at first glance look just fine.
112 | But I took a closer look at them, and here's a short list of the problems
113 | in the patches that were sent to me.
114 |
115 | ---------
116 |
117 | Subject: [PATCH 48/48] ....
118 |
119 | There were no 47 previous patches
120 |
121 | ---------
122 |
123 | 15 sequence patch series, no order given.
124 |
125 | Am I supposed to guess?
126 |
127 | ---------
128 |
129 | Patches 1,3-10, #2 never showed up
130 |
131 | ---------
132 |
133 | "Signed-off-by:" in signature
134 |
135 | This would require me to edit the patch by hand before I applied it.
136 |
137 | ---------
138 |
139 | Signature saying email was confidential
140 |
141 | That kind of goes against how you are supposed to be sending Linux kernel
142 | patches out to the world.
143 |
144 | ---------
145 |
146 | Tabs converted to spaces
147 |
148 | This makes applying the patch impossible.
149 |
150 | Exchange does this for you, if you are working for a corporation that has
151 | an Exchange server, do what IBM, Intel, and Microsoft have done in order to
152 | be able to contribute to Linux kernel development, have a Linux box
153 | somewhere in the corner that your developers use as a mail server to send
154 | patches out from.
155 |
156 | Huawei is the only company that I know of that successfully sends kernel
157 | patches through an Exchange server, which is amazing, I really don't know
158 | how they do it.
159 |
160 | ---------
161 |
162 | Leading spaces removed
163 |
164 | This also makes applying the patch impossible. I end up editing a lot of
165 | patches by hand, cursing all the while, just to get them to apply because
166 | of broken email servers and clients.
167 |
168 | ---------
169 |
170 | diff in non-unified format
171 |
172 | I honestly didn't know that diff could still create output in this format
173 | anymore, I assumed that as no one ever found it useful, it wasn't used
174 | anymore.
175 |
176 | ---------
177 |
178 | patch created in the driver directory
179 |
180 | Patches need to be created in the root of the kernel source tree, as that's
181 | where I have to be in order to apply them properly.
182 |
183 | This seems to happen a lot to first-time patch submitters, it's a very
184 | common problem.
185 |
186 | ---------
187 |
188 | patch created at /usr/src/linux-2.6.32/
189 |
190 | How many different problems can you see here in just this one example?
191 |
192 | Old and obsolete kernel version, full path to root, developer doing kernel
193 | work as root, probably more.
194 |
195 | ---------
196 |
197 | Made against different tree
198 |
199 | Someone made a patch against the scsi subsystem development tree when
200 | sending me a USB patch. Why they thought that was a good idea I have no
201 | idea.
202 |
203 | ---------
204 |
205 | Wrong coding style
206 |
207 | There's no excuse for doing something like this anymore, we have automated
208 | tools that fix this up for you.
209 |
210 | ---------
211 |
212 | Wrong coding style, and acknowledged it
213 |
214 | At least in this patch, the author knew they were doing something wrong,
215 | It's just that they thought they were more important than the 3000 other
216 | kernel developers and didn't have to play by the rules of everyone else.
217 |
218 | ---------
219 |
220 | Would not compile
221 |
222 | Just looking at the patch it was obvious that it had never been compiled,
223 | and sure enough, the compiler spit out a bunch of errors.
224 |
225 | ---------
226 |
227 | Broke the build on patch 3/6
228 |
229 | This was a series of patches, and the build broke on the 3rd patch that was
230 | applied.
231 |
232 | ---------
233 |
234 | Broke the build on patch 3/6
235 | and fixed it on patch 6/6
236 |
237 | But, I looked closer, and the developer at least realized this, and fixed
238 | it in their last patch in the series, thinking that all was now good, as it
239 | didn't really matter that for the past 3 patches, the build was broken.
240 |
241 | ---------
242 |
243 | Broke the build on patch 5/8
244 |
245 | There was another patch series that also broke the build in the middle of it.
246 |
247 | ---------
248 |
249 | Broke the build on patch 5/8
250 | Contained note that fix would be sent later.
251 |
252 | But this one was better, it had a note saying that they knew the build was
253 | broken, and they would fix it up later, at some unknown time in the future,
254 | but these 8 patches should be accepted now anyway.
255 |
256 | ---------
257 |
258 | Patches that had nothing to do with me.
259 |
260 | Now I know I maintain a lot of different parts of the kernel, but for some
261 | reason someone sent me a patch for the x86 core code, copied to no one
262 | else, thinking that I was the one that could accept it.
263 |
264 | ---------
265 |
266 | 1 patch that was 145kb big (4500 lines added)
267 |
268 | Luckily, another developer told the author that this was too big and needed
269 | to be broken up into smaller pieces before anyone would review it. And
270 | then, three different developers went and reviewed it anyway, so I don't
271 | think the author learned that lesson at all.
272 |
273 | ---------
274 |
275 | Obviously wrong kerneldoc
276 |
277 | kerneldoc is the format that you can write comments in the code and get
278 | them included in the kernel api documentation that is automatically
279 | generated. When you get the format of it wrong, the tools will tell you.
280 |
281 | Here was someone who was trying to write documentation, but got the format
282 | wrong, and hadn't even run the tools to see if it was generated properly.
283 |
284 | ---------
285 |
286 | This was a calm 2 weeks.
287 |
288 | Now, I'm not asking you to take pity on me, just realize that this is the
289 | level of incompetence that every single one of those 700 maintainers
290 | encounter all the time.
291 |
292 | So when you think we are acting grumpy, remember, how would you act if you
293 | had to deal with this all of the time?
294 |
295 | Let's get back to what the goal is here. You want to create a patch that
296 | is accepted as it does something that you want to do in Linux. The
297 | maintainer wants to reject it.
298 |
299 | ---------
300 |
301 | It is in my self-interest to ignore your patch
302 |
303 | Seriously. It's easier for the me to not accept your code at all. To
304 | accept it, it takes time to review it, apply it, send it on up the
305 | development chain, handle any problems that might happen with the patch,
306 | accept responsibility for the patch, possibly fix any problems that happen
307 | later on when you disappear, and maintain it for the next 20 years.
308 |
309 | That's a lot of work that you are asking someone else to do on your behalf.
310 | You are asking someone who doesn't usually work for your company, who
311 | probably lives in a different country, who you have never met in person, to
312 | assume responsibility for your work, and to do extra work on top of the
313 | normal work they do in the kernel every day.
314 |
315 | So you can see how it's in my interest to ignore your patch. And it's in
316 | your interest to keep me from ignoring it, because you want it accepted.
317 |
318 | ---------
319 |
320 | Give me no excuse to reject your patch
321 |
322 | So your goal is, when sending a patch, is to give me NO excuse to not
323 | accept it. To make it such that if I ignore it, or reject it, I am the one
324 | that is the problem here, not you.
325 |
326 | What can you do to keep me from rejecting your patch outright.
327 |
328 | First off, don't do any of the things I listed above, that's obvious,
329 | right? But that's a "do not do" list, how about a list of what to do:
330 |
331 |
332 | ---------
333 |
334 | Proper coding style
335 |
336 | This is documented, there should not be any reason to ever get this wrong.
337 | Or to think that you are above following the rules, that's just asking for
338 | the patch to be rejected.
339 |
340 | ---------
341 |
342 | scripts/checkpatch.pl clean
343 |
344 | We even have a tool that automatically checks your patch to ensure that you
345 | got the coding style correct, and that other common problems are avoided.
346 |
347 | If you don't run this tool, the maintainer will, and will get mad when it
348 | finds problems that you should have solved before sending it to them.
349 |
350 | ---------
351 |
352 | Sent to proper people and lists
353 |
354 | I have an email bot that if you ever send a patch to only me, and not any
355 | mailing list, instantly rejects it and tells you to resend it and copy the
356 | proper people and mailing lists.
357 |
358 | Linux kernel development is done in public, not private, and it doesn't
359 | scale to send patches or emails to only individual developers. We all have
360 | subsystem-specific mailing lists, use them, that way other people can
361 | review your patches, and comment on them, and you don't overburden the
362 | individual subsystem maintainers any more than they already are.
363 |
364 | ---------
365 |
366 | Sent to proper people and lists
367 |
368 | scripts/get_maintainer.pl
369 |
370 | Look, we even have a tool that you run on your patch, and it digs through
371 | the MAINTAINERS file and the git history, and figures out who to send the
372 | patch to, and what mailing lists to copy at the same time.
373 |
374 | Use it.
375 |
376 | ---------
377 |
378 | Proper Subject:
379 |
380 | Make the subject of your patch something that makes sense.
381 |
382 | Don't send me a 20 patch series that for every individual patch says,
383 | "Fixes problems in driver" like some people have done in the past.
384 |
385 | ---------
386 |
387 | Proper changelog comment
388 |
389 | In the body of the email, describe the patch, what it does. And most
390 | importantly:
391 |
392 | ---------
393 |
394 | Description of WHY it is needed
395 |
396 | Too many times we see patches that say exactly what the patch does. Which
397 | is stupid because we know how to read code, what we want to know is why the
398 | change is being made, and from that we can determine if it really is needed
399 | or not.
400 |
401 | ---------
402 |
403 | Small incremental change
404 |
405 | Patches are not supposed to be big huge rewrites of things. That's not how
406 | we do development. You need to make each patch a small one-item change.
407 |
408 | Break your larger change up into a set of small, individual, steps. Like
409 | your math professor said, "show your work". We want to see all the steps
410 | you make along the way to complete your larger goal.
411 |
412 |
413 | ---------
414 |
415 | "obviously" correct
416 |
417 | Make it the patch is so simple and obvious that I would be foolish to
418 | reject it. I need to read it and say, "of course, I can't belive we didn't
419 | do that in the past, how stupid we never did this before!"
420 |
421 | ---------
422 |
423 | Which tree it was made against
424 |
425 | If you create a patch against a different development tree than the person
426 | you are sending it to, let them know. If you made it against an obsolete
427 | vendor enterprise kernel release, tell them. Don't make them guess.
428 |
429 | If you make me guess, I will guess wrong, that's just the way it goes.
430 |
431 | ---------
432 |
433 | If multiple patches, state the order
434 |
435 | Number your patches, don't rely on my email client receiving them in the
436 | same order that you sent them in. I guarantee that will not happen
437 | properly.
438 |
439 | git send-email does this correctly for you, use that to send your patches
440 | out.
441 |
442 | ---------
443 |
444 | Has to build properly
445 |
446 | At least build the change before you send it to me. Because if it breaks
447 | the build, it just makes me more likely to not want to apply anything else
448 | you send me in the future, as you are just wasting my time.
449 |
450 |
451 | ---------
452 |
453 | Make sure it works, if possible
454 |
455 | If you have the hardware, test the patch. Now that isn't always possible,
456 | and that's fine, we make changes to drivers for hardware that we don't have
457 | access to all the time, which seems to surprise a lot of people.
458 |
459 | Go back to that "obviously correct" item, if you don't have the hardware,
460 | stick to that rule and you will be fine.
461 |
462 | ---------
463 |
464 | Don't ignore review comments
465 |
466 | Lots of time I see patches sent out on Friday afternoon, and then the
467 | author disappears on a 2 week vacation. So, when I spend the time
468 | reviewing the patches, I get back a vacation bounce message.
469 |
470 | And, if the email does go through, don't ignore it. Acknowledge it, either
471 | agreeing or pushing back on the comments.
472 |
473 | If you don't acknowledge the effort I just spent in reviewing your
474 | submission, that will make me very unlikely to ever want to review it again
475 | in the future.
476 |
477 | ---------
478 |
479 | Don't resend without saying why
480 |
481 | If you take my review comments, and resend the patch, and don't say what
482 | you did different from the first patch submission, I'll think that you just
483 | ignored everything that I said in the past and just delete the patch from
484 | my mailbox. Based on the patch load I get, I can't remember what I wrote
485 | about your specific patch, so don't assume that I do.
486 |
487 | ---------
488 |
489 | What I will do for you:
490 |
491 | So, finally, you created the perfect patch series, took all review into
492 | account, and sent it correctly, without corrupting the patch. What should
493 | you expect from me, the subsystem maintainer?
494 |
495 |
496 | ---------
497 | Review your patch within 1-2 weeks
498 |
499 | Some subsystem maintainers try to get to patches even faster than this, but
500 | with travel and different conferences, the best that I can normally do is
501 | about 1-2 weeks.
502 |
503 | If I don't respond in that time frame, just ask what is going on. I have
504 | no problem with people asking about their patch status. Sometimes patches
505 | end up getting dropped on the floor accidentally, and if I'm being slow I
506 | have no problem with being called on it, so don't feel bad about checking
507 | up on it.
508 |
509 | But please wait 1-2 weeks, don't be rude and send a patch at night, and
510 | then in the morning send a complaining email asking why it wasn't reviewed
511 | already. This happens more than you want to know.
512 |
513 | ---------
514 | Offer semi-constructive criticism
515 |
516 | I can't always promise constructive criticism, but I'll try my best.
517 |
518 | ---------
519 | Let you know the status of your patch
520 |
521 | I have a set of scripts that I got from Andrew Morton that will email you
522 | when I apply your patch to one of my development trees saying where it has
523 | been applied and when you can expect to see it show up in Linus's tree.
524 | There is no reason that all kernel maintainers shouldn't do this, and it's
525 | nice to see that more and more are.
526 |
527 | But, I know from personal experience, there are maintainers in this room
528 | today that I send patches to and I never know what happens to them. A few
529 | months later I will see them show up in Linus's tree, usually after I
530 | forgot about them.
531 |
532 | That's not acceptable, and you should not allow this, push back on your
533 | subsystem maintainer to use something like this, to keep you informed.
534 | Andrew's scripts are public, as are my variations of them, for everyone to
535 | use.
536 |
537 | ---------
538 |
539 | Linus quote:
540 |
541 | Publicly making fun of people is half the fun of open source
542 | programming.
543 |
544 | In fact, the real reason to eschew programming in closed
545 | environments is that you can't embarrass people in public.
546 |
547 | Linus said this after I wrote a small rant about some truly horrible
548 | Linux kernel driver code that I found online.
549 |
550 | It had all sorts of "this code is never to be included in the Linux
551 | kernel" warnings all over it, despite it being a Linux kernel driver.
552 | And in reading the code, it was obvious why the author never wanted it
553 | in the kernel, it was one of the worse things I had ever seen, and that
554 | says a lot. After I complained about it, I felt bad, as someone had
555 | obviously spent a lot of time on it, but Linus replied with the above
556 | quote.
557 |
558 | And as always, it turns out that Linus is right.
559 |
560 | If that author had ever thought that the code would have been posted
561 | publicly, they wouldn't have written such crap. That's what maintainers
562 | and public code review is really for in the end, keeping the crap out of
563 | the Linux kernel, which benefits everyone involved.
564 |
565 | So while it seems that we kernel developers can be a real harsh bunch of
566 | people, it is because of that harshness that Linux is as good as it is.
567 |
568 | You want us to be tough, because it makes you better programmers in the
569 | end, knowing you will have to defend your code.
570 |
571 | And that is why I love doing this work, it makes everyone involved produce
572 | the best possible code, which in the end, is what matters the most.
573 |
574 |
--------------------------------------------------------------------------------
/notes:
--------------------------------------------------------------------------------
1 | Ways to piss off a maintainer with patches you send them:
2 |
3 | - html patch
4 | - other patch email client issues (outlook, line-wrapping, mime, base64,
5 | wierd extra spaces, tabs to spaces, etc.)
6 | - patch does not apply
7 | - patch does not build
8 | - multiple patches with no ordering indicated
9 | - patch made against unknown tree
10 | - patch made against old kernel tree
11 | - ask me to pull random git trees with no description of what is in them
12 | - multi-patch series that breaks the build half way through the series
13 | - patches that blindly do checkpatch cleanups without realizing what
14 | they are fixing
15 | - patches that do more than one thing in the patch
16 | - fixes for compiler warnings that are due to old versions of gcc not
17 | being smart (hint, upgrade your version of gcc)
18 |
19 |
20 | (from my long-running series of how to piss off a maintainer)
21 | - sent patches to a different maintainer to try to route around you
22 | (luckily, doesn't happen much anymore)
23 | - send patches with wrong 'offset' requiring them to be edited by hand
24 | - ignore coding style issues
25 | - send patches that depend on others to work or apply properly, yet
26 | never mention this
27 | - patches add new compiler warnings
28 | - patches that oops when run, and were obviously not tested
29 | - paper over kernel warning messages by providing empty callback
30 | functions (the kernel was making those warnings for a good reason, are
31 | you smarter than the kernel? Really?)
32 | - description of patch is opposite of what the patch actually did.
33 | - multiple patches sent with exact same subject
34 | - patches to clean up coding style issues that add new coding style warnings
35 | - patches asked for review, yet obviously never even run through our
36 | automated review tools
37 | - constant emails asking why you haven't applied their 117-patch series
38 | they sent out yesterday. Emails sent in html format and not to the
39 | mailing list
40 | - private emails not sent to mailing lists
41 |
42 |
43 | Stable patch specific review rants:
44 | - patches sent with the wrong upstream git commit id in them.
45 | - patches that differ in major ways from the upstream patch without saying that they are different
46 | - patches sent with no information on what stable kernel they should be applied to
47 | - patches sent with no git commit id
48 | - patches that obviously do not meet the stable_kernel_rules.txt rules (spelling fixes for comments? You have got to be kidding me...)
49 |
--------------------------------------------------------------------------------
/show_presentation.sh:
--------------------------------------------------------------------------------
1 | #!/bin/bash
2 |
3 | # Reset terminal to current state when we exit.
4 | trap "stty $(stty -g)" EXIT
5 |
6 | # Disable echo and special characters, set input timeout to 0.2 seconds.
7 | stty -echo -icanon time 2 || exit $?
8 |
9 | # String containing all keypresses.
10 | KEYS=""
11 |
12 | # Set field separator to BEL (should not occur in keypresses)
13 | IFS=$'\a'
14 |
15 | SELECTION=""
16 |
17 |
18 | # The logitech presenter device is a keyboard with 6 buttons:
19 | # Button keycode
20 | # left arrow page-up
21 | # right arrow page-down
22 | # Monitor '.'
23 | # F5/esc Alternates between F5 and Esc
24 | # volume up volume-up
25 | # volume down volume-down
26 | #
27 | # we are going to use left and right arrows to make the selection of the file,
28 | # and the monitor button as the "select me" option. Everything else will be
29 | # ignored.
30 | # to be nice on testing on a keyboard, let's also use the right and left and up
31 | # and down arrows to change the selection.
32 | #
33 | # This functions returns the key in the ${SELECTION} variable as:
34 | # 'R' - move right
35 | # 'L' - move left
36 | # 'P' - make this selection
37 | get_selection()
38 | {
39 | # Input loop.
40 | while [ 1 ]; do
41 |
42 | SELECTION=""
43 |
44 | # Read more input from keyboard when necessary.
45 | while read -t 0 ; do
46 | read -s -r -d "" -N 1 -t 0.2 CHAR && KEYS="$KEYS$CHAR" || break
47 | done
48 |
49 | # If no keys to process, wait 0.05 seconds and retry.
50 | if [ -z "$KEYS" ]; then
51 | sleep 0.05
52 | continue
53 | fi
54 |
55 | # Check the first (next) keypress in the buffer.
56 | case "$KEYS" in
57 |
58 | $'\x1B\x5B\x41'*) # Up
59 | KEYS="${KEYS##???}"
60 | #echo "Up"
61 | SELECTION="L"
62 | ;;
63 | $'\x1B\x5B\x42'*) # Down
64 | KEYS="${KEYS##???}"
65 | #echo "Down"
66 | SELECTION="R"
67 | ;;
68 | $'\x1B\x5B\x44'*) # Left
69 | KEYS="${KEYS##???}"
70 | #echo "Left"
71 | SELECTION="L"
72 | ;;
73 | $'\x1B\x5B\x43'*) # Right
74 | KEYS="${KEYS##???}"
75 | #echo "Right"
76 | SELECTION="R"
77 | ;;
78 | $'\x1B\x5B\x35\x7e'*) # PageUp
79 | KEYS="${KEYS##????}"
80 | #echo "PageUp"
81 | SELECTION="L"
82 | ;;
83 | $'\x1B\x5B\x36\x7e'*) # PageDown
84 | KEYS="${KEYS##????}"
85 | #echo "PageDown"
86 | SELECTION="R"
87 | ;;
88 | $'.'*) # 'period'
89 | KEYS="${KEYS##?}"
90 | SELECTION="P"
91 | ;;
92 | $'\x1B\x5B\x31\x35\x7e'*) # F5
93 | KEYS="${KEYS##?????}"
94 | #echo "F5"
95 | ;;
96 | $'\n'*|$'\r'*) # Enter/Return
97 | KEYS="${KEYS##?}"
98 | #echo "Enter or Return"
99 | SELECTION="P"
100 | ;;
101 | $'\x1B') # Esc (without anything following!)
102 | KEYS="${KEYS##?}"
103 | #echo "Esc"
104 | ;;
105 | $'\x1B'*) # Unknown escape sequences
106 | #echo -n "Unknown escape sequence (${#KEYS} chars): \$'"
107 | #echo -n "$KEYS" | od --width=256 -t x1 | sed -e '2,99 d; s|^[0-9A-Fa-f]* ||; s| |\\x|g; s|$|'"'|"
108 | KEYS=""
109 | ;;
110 | [$'\x01'-$'\x1F'$'\x7F']*) # Consume control characters
111 | KEYS="${KEYS##?}"
112 | ;;
113 | *) # Printable characters.
114 | KEY="${KEYS:0:1}"
115 | KEYS="${KEYS#?}"
116 | #echo "'$KEY'"
117 | ;;
118 | esac
119 |
120 | if [ "${SELECTION}" == "" ] ; then
121 | continue;
122 | else
123 | #echo "Selection = '${SELECTION}'"
124 | break;
125 | fi
126 | done
127 | }
128 |
129 | while [ 1 ] ; do
130 |
131 | for pdf in *.pdf ; do
132 | echo -n "Press 'monitor key' to run the ${pdf} presentation."
133 | get_selection
134 | echo ""
135 | if [ "${SELECTION}" == "P" ] ; then
136 | evince ${pdf} &
137 | #exit 0
138 | fi
139 | done
140 | done
141 |
--------------------------------------------------------------------------------
/template/lf_template.odp:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/gregkh/presentation-linux-maintainer/32a5867f2f1bdeececf9ebd674fbd21493f89c90/template/lf_template.odp
--------------------------------------------------------------------------------
/template/lf_template_2.svg:
--------------------------------------------------------------------------------
1 |
--------------------------------------------------------------------------------