├── 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 | --------------------------------------------------------------------------------