Commit | Line | Data |
---|---|---|
f7c9fe4b MCC |
1 | .. _development_process: |
2 | ||
3 | How the development process works | |
4 | ================================= | |
75b02146 JC |
5 | |
6 | Linux kernel development in the early 1990's was a pretty loose affair, | |
7 | with relatively small numbers of users and developers involved. With a | |
8 | user base in the millions and with some 2,000 developers involved over the | |
9 | course of one year, the kernel has since had to evolve a number of | |
10 | processes to keep development happening smoothly. A solid understanding of | |
11 | how the process works is required in order to be an effective part of it. | |
12 | ||
f7c9fe4b MCC |
13 | The big picture |
14 | --------------- | |
75b02146 JC |
15 | |
16 | The kernel developers use a loosely time-based release process, with a new | |
17 | major kernel release happening every two or three months. The recent | |
18 | release history looks like this: | |
19 | ||
f7c9fe4b | 20 | ====== ================= |
fb0e0ffe TF |
21 | 5.0 March 3, 2019 |
22 | 5.1 May 5, 2019 | |
23 | 5.2 July 7, 2019 | |
24 | 5.3 September 15, 2019 | |
25 | 5.4 November 24, 2019 | |
26 | 5.5 January 6, 2020 | |
f7c9fe4b | 27 | ====== ================= |
75b02146 | 28 | |
fb0e0ffe TF |
29 | Every 5.x release is a major kernel release with new features, internal |
30 | API changes, and more. A typical release can contain about 13,000 | |
31 | changesets with changes to several hundred thousand lines of code. 5.x is | |
32 | the leading edge of Linux kernel development; the kernel uses a | |
75b02146 JC |
33 | rolling development model which is continually integrating major changes. |
34 | ||
35 | A relatively straightforward discipline is followed with regard to the | |
36 | merging of patches for each release. At the beginning of each development | |
37 | cycle, the "merge window" is said to be open. At that time, code which is | |
38 | deemed to be sufficiently stable (and which is accepted by the development | |
39 | community) is merged into the mainline kernel. The bulk of changes for a | |
40 | new development cycle (and all of the major changes) will be merged during | |
41 | this time, at a rate approaching 1,000 changes ("patches," or "changesets") | |
42 | per day. | |
43 | ||
44 | (As an aside, it is worth noting that the changes integrated during the | |
45 | merge window do not come out of thin air; they have been collected, tested, | |
46 | and staged ahead of time. How that process works will be described in | |
47 | detail later on). | |
48 | ||
5c050fb9 JC |
49 | The merge window lasts for approximately two weeks. At the end of this |
50 | time, Linus Torvalds will declare that the window is closed and release the | |
fb0e0ffe | 51 | first of the "rc" kernels. For the kernel which is destined to be 5.6, |
5c050fb9 | 52 | for example, the release which happens at the end of the merge window will |
fb0e0ffe | 53 | be called 5.6-rc1. The -rc1 release is the signal that the time to |
5c050fb9 JC |
54 | merge new features has passed, and that the time to stabilize the next |
55 | kernel has begun. | |
75b02146 JC |
56 | |
57 | Over the next six to ten weeks, only patches which fix problems should be | |
58 | submitted to the mainline. On occasion a more significant change will be | |
59 | allowed, but such occasions are rare; developers who try to merge new | |
60 | features outside of the merge window tend to get an unfriendly reception. | |
61 | As a general rule, if you miss the merge window for a given feature, the | |
62 | best thing to do is to wait for the next development cycle. (An occasional | |
63 | exception is made for drivers for previously-unsupported hardware; if they | |
64 | touch no in-tree code, they cannot cause regressions and should be safe to | |
65 | add at any time). | |
66 | ||
67 | As fixes make their way into the mainline, the patch rate will slow over | |
68 | time. Linus releases new -rc kernels about once a week; a normal series | |
69 | will get up to somewhere between -rc6 and -rc9 before the kernel is | |
fb0e0ffe | 70 | considered to be sufficiently stable and the final release is made. |
75b02146 JC |
71 | At that point the whole process starts over again. |
72 | ||
fb0e0ffe TF |
73 | As an example, here is how the 5.4 development cycle went (all dates in |
74 | 2019): | |
5c050fb9 | 75 | |
f7c9fe4b | 76 | ============== =============================== |
fb0e0ffe TF |
77 | September 15 5.3 stable release |
78 | September 30 5.4-rc1, merge window closes | |
79 | October 6 5.4-rc2 | |
80 | October 13 5.4-rc3 | |
81 | October 20 5.4-rc4 | |
82 | October 27 5.4-rc5 | |
83 | November 3 5.4-rc6 | |
84 | November 10 5.4-rc7 | |
85 | November 17 5.4-rc8 | |
86 | November 24 5.4 stable release | |
f7c9fe4b | 87 | ============== =============================== |
75b02146 JC |
88 | |
89 | How do the developers decide when to close the development cycle and create | |
90 | the stable release? The most significant metric used is the list of | |
91 | regressions from previous releases. No bugs are welcome, but those which | |
92 | break systems which worked in the past are considered to be especially | |
93 | serious. For this reason, patches which cause regressions are looked upon | |
94 | unfavorably and are quite likely to be reverted during the stabilization | |
5c050fb9 | 95 | period. |
75b02146 JC |
96 | |
97 | The developers' goal is to fix all known regressions before the stable | |
98 | release is made. In the real world, this kind of perfection is hard to | |
99 | achieve; there are just too many variables in a project of this size. | |
100 | There comes a point where delaying the final release just makes the problem | |
101 | worse; the pile of changes waiting for the next merge window will grow | |
fb0e0ffe | 102 | larger, creating even more regressions the next time around. So most 5.x |
75b02146 JC |
103 | kernels go out with a handful of known regressions though, hopefully, none |
104 | of them are serious. | |
105 | ||
106 | Once a stable release is made, its ongoing maintenance is passed off to the | |
fb0e0ffe TF |
107 | "stable team," currently Greg Kroah-Hartman. The stable team will release |
108 | occasional updates to the stable release using the 5.x.y numbering scheme. | |
109 | To be considered for an update release, a patch must (1) fix a significant | |
110 | bug, and (2) already be merged into the mainline for the next development | |
111 | kernel. Kernels will typically receive stable updates for a little more | |
112 | than one development cycle past their initial release. So, for example, the | |
113 | 5.2 kernel's history looked like this (all dates in 2019): | |
5c050fb9 | 114 | |
f7c9fe4b | 115 | ============== =============================== |
fb0e0ffe TF |
116 | September 15 5.2 stable release |
117 | July 14 5.2.1 | |
118 | July 21 5.2.2 | |
119 | July 26 5.2.3 | |
120 | July 28 5.2.4 | |
121 | July 31 5.2.5 | |
8962e40c | 122 | ... ... |
fb0e0ffe | 123 | October 11 5.2.21 |
f7c9fe4b | 124 | ============== =============================== |
5c050fb9 | 125 | |
fb0e0ffe | 126 | 5.2.21 was the final stable update of the 5.2 release. |
5c050fb9 JC |
127 | |
128 | Some kernels are designated "long term" kernels; they will receive support | |
129 | for a longer period. As of this writing, the current long term kernels | |
130 | and their maintainers are: | |
131 | ||
fb0e0ffe TF |
132 | ====== ================================ ======================= |
133 | 3.16 Ben Hutchings (very long-term kernel) | |
134 | 4.4 Greg Kroah-Hartman & Sasha Levin (very long-term kernel) | |
135 | 4.9 Greg Kroah-Hartman & Sasha Levin | |
136 | 4.14 Greg Kroah-Hartman & Sasha Levin | |
137 | 4.19 Greg Kroah-Hartman & Sasha Levin | |
138 | 5.4 Greg Kroah-Hartman & Sasha Levin | |
139 | ====== ================================ ======================= | |
5c050fb9 JC |
140 | |
141 | The selection of a kernel for long-term support is purely a matter of a | |
142 | maintainer having the need and the time to maintain that release. There | |
143 | are no known plans for long-term support for any specific upcoming | |
144 | release. | |
75b02146 JC |
145 | |
146 | ||
f7c9fe4b MCC |
147 | The lifecycle of a patch |
148 | ------------------------ | |
75b02146 JC |
149 | |
150 | Patches do not go directly from the developer's keyboard into the mainline | |
151 | kernel. There is, instead, a somewhat involved (if somewhat informal) | |
152 | process designed to ensure that each patch is reviewed for quality and that | |
153 | each patch implements a change which is desirable to have in the mainline. | |
154 | This process can happen quickly for minor fixes, or, in the case of large | |
155 | and controversial changes, go on for years. Much developer frustration | |
156 | comes from a lack of understanding of this process or from attempts to | |
5c050fb9 | 157 | circumvent it. |
75b02146 JC |
158 | |
159 | In the hopes of reducing that frustration, this document will describe how | |
160 | a patch gets into the kernel. What follows below is an introduction which | |
161 | describes the process in a somewhat idealized way. A much more detailed | |
162 | treatment will come in later sections. | |
163 | ||
164 | The stages that a patch goes through are, generally: | |
165 | ||
166 | - Design. This is where the real requirements for the patch - and the way | |
167 | those requirements will be met - are laid out. Design work is often | |
168 | done without involving the community, but it is better to do this work | |
169 | in the open if at all possible; it can save a lot of time redesigning | |
170 | things later. | |
171 | ||
172 | - Early review. Patches are posted to the relevant mailing list, and | |
173 | developers on that list reply with any comments they may have. This | |
174 | process should turn up any major problems with a patch if all goes | |
175 | well. | |
176 | ||
177 | - Wider review. When the patch is getting close to ready for mainline | |
ef0eba47 | 178 | inclusion, it should be accepted by a relevant subsystem maintainer - |
75b02146 JC |
179 | though this acceptance is not a guarantee that the patch will make it |
180 | all the way to the mainline. The patch will show up in the maintainer's | |
e4fabad3 | 181 | subsystem tree and into the -next trees (described below). When the |
75b02146 JC |
182 | process works, this step leads to more extensive review of the patch and |
183 | the discovery of any problems resulting from the integration of this | |
184 | patch with work being done by others. | |
185 | ||
ef0eba47 RD |
186 | - Please note that most maintainers also have day jobs, so merging |
187 | your patch may not be their highest priority. If your patch is | |
188 | getting feedback about changes that are needed, you should either | |
189 | make those changes or justify why they should not be made. If your | |
190 | patch has no review complaints but is not being merged by its | |
191 | appropriate subsystem or driver maintainer, you should be persistent | |
192 | in updating the patch to the current kernel so that it applies cleanly | |
193 | and keep sending it for review and merging. | |
194 | ||
75b02146 JC |
195 | - Merging into the mainline. Eventually, a successful patch will be |
196 | merged into the mainline repository managed by Linus Torvalds. More | |
197 | comments and/or problems may surface at this time; it is important that | |
198 | the developer be responsive to these and fix any issues which arise. | |
199 | ||
200 | - Stable release. The number of users potentially affected by the patch | |
201 | is now large, so, once again, new problems may arise. | |
202 | ||
203 | - Long-term maintenance. While it is certainly possible for a developer | |
204 | to forget about code after merging it, that sort of behavior tends to | |
205 | leave a poor impression in the development community. Merging code | |
206 | eliminates some of the maintenance burden, in that others will fix | |
207 | problems caused by API changes. But the original developer should | |
208 | continue to take responsibility for the code if it is to remain useful | |
209 | in the longer term. | |
210 | ||
211 | One of the largest mistakes made by kernel developers (or their employers) | |
212 | is to try to cut the process down to a single "merging into the mainline" | |
213 | step. This approach invariably leads to frustration for everybody | |
214 | involved. | |
215 | ||
f7c9fe4b MCC |
216 | How patches get into the Kernel |
217 | ------------------------------- | |
75b02146 JC |
218 | |
219 | There is exactly one person who can merge patches into the mainline kernel | |
fb0e0ffe TF |
220 | repository: Linus Torvalds. But, for example, of the over 9,500 patches |
221 | which went into the 2.6.38 kernel, only 112 (around 1.3%) were directly | |
222 | chosen by Linus himself. The kernel project has long since grown to a size | |
223 | where no single developer could possibly inspect and select every patch | |
224 | unassisted. The way the kernel developers have addressed this growth is | |
225 | through the use of a lieutenant system built around a chain of trust. | |
75b02146 JC |
226 | |
227 | The kernel code base is logically broken down into a set of subsystems: | |
228 | networking, specific architecture support, memory management, video | |
229 | devices, etc. Most subsystems have a designated maintainer, a developer | |
230 | who has overall responsibility for the code within that subsystem. These | |
231 | subsystem maintainers are the gatekeepers (in a loose way) for the portion | |
232 | of the kernel they manage; they are the ones who will (usually) accept a | |
233 | patch for inclusion into the mainline kernel. | |
234 | ||
235 | Subsystem maintainers each manage their own version of the kernel source | |
236 | tree, usually (but certainly not always) using the git source management | |
237 | tool. Tools like git (and related tools like quilt or mercurial) allow | |
238 | maintainers to track a list of patches, including authorship information | |
239 | and other metadata. At any given time, the maintainer can identify which | |
240 | patches in his or her repository are not found in the mainline. | |
241 | ||
242 | When the merge window opens, top-level maintainers will ask Linus to "pull" | |
243 | the patches they have selected for merging from their repositories. If | |
244 | Linus agrees, the stream of patches will flow up into his repository, | |
245 | becoming part of the mainline kernel. The amount of attention that Linus | |
246 | pays to specific patches received in a pull operation varies. It is clear | |
247 | that, sometimes, he looks quite closely. But, as a general rule, Linus | |
248 | trusts the subsystem maintainers to not send bad patches upstream. | |
249 | ||
250 | Subsystem maintainers, in turn, can pull patches from other maintainers. | |
251 | For example, the networking tree is built from patches which accumulated | |
252 | first in trees dedicated to network device drivers, wireless networking, | |
253 | etc. This chain of repositories can be arbitrarily long, though it rarely | |
254 | exceeds two or three links. Since each maintainer in the chain trusts | |
255 | those managing lower-level trees, this process is known as the "chain of | |
5c050fb9 | 256 | trust." |
75b02146 JC |
257 | |
258 | Clearly, in a system like this, getting patches into the kernel depends on | |
259 | finding the right maintainer. Sending patches directly to Linus is not | |
260 | normally the right way to go. | |
261 | ||
262 | ||
f7c9fe4b MCC |
263 | Next trees |
264 | ---------- | |
75b02146 JC |
265 | |
266 | The chain of subsystem trees guides the flow of patches into the kernel, | |
267 | but it also raises an interesting question: what if somebody wants to look | |
268 | at all of the patches which are being prepared for the next merge window? | |
269 | Developers will be interested in what other changes are pending to see | |
270 | whether there are any conflicts to worry about; a patch which changes a | |
271 | core kernel function prototype, for example, will conflict with any other | |
272 | patches which use the older form of that function. Reviewers and testers | |
273 | want access to the changes in their integrated form before all of those | |
274 | changes land in the mainline kernel. One could pull changes from all of | |
275 | the interesting subsystem trees, but that would be a big and error-prone | |
276 | job. | |
277 | ||
e4fabad3 | 278 | The answer comes in the form of -next trees, where subsystem trees are |
75b02146 JC |
279 | collected for testing and review. The older of these trees, maintained by |
280 | Andrew Morton, is called "-mm" (for memory management, which is how it got | |
281 | started). The -mm tree integrates patches from a long list of subsystem | |
5c050fb9 | 282 | trees; it also has some patches aimed at helping with debugging. |
75b02146 JC |
283 | |
284 | Beyond that, -mm contains a significant collection of patches which have | |
285 | been selected by Andrew directly. These patches may have been posted on a | |
286 | mailing list, or they may apply to a part of the kernel for which there is | |
287 | no designated subsystem tree. As a result, -mm operates as a sort of | |
288 | subsystem tree of last resort; if there is no other obvious path for a | |
289 | patch into the mainline, it is likely to end up in -mm. Miscellaneous | |
290 | patches which accumulate in -mm will eventually either be forwarded on to | |
291 | an appropriate subsystem tree or be sent directly to Linus. In a typical | |
5c050fb9 JC |
292 | development cycle, approximately 5-10% of the patches going into the |
293 | mainline get there via -mm. | |
75b02146 | 294 | |
e6a591e5 RD |
295 | The current -mm patch is available in the "mmotm" (-mm of the moment) |
296 | directory at: | |
75b02146 | 297 | |
e7b4311e | 298 | https://www.ozlabs.org/~akpm/mmotm/ |
75b02146 JC |
299 | |
300 | Use of the MMOTM tree is likely to be a frustrating experience, though; | |
301 | there is a definite chance that it will not even compile. | |
302 | ||
5c050fb9 | 303 | The primary tree for next-cycle patch merging is linux-next, maintained by |
75b02146 JC |
304 | Stephen Rothwell. The linux-next tree is, by design, a snapshot of what |
305 | the mainline is expected to look like after the next merge window closes. | |
306 | Linux-next trees are announced on the linux-kernel and linux-next mailing | |
307 | lists when they are assembled; they can be downloaded from: | |
308 | ||
e7b4311e | 309 | https://www.kernel.org/pub/linux/kernel/next/ |
75b02146 | 310 | |
5c050fb9 JC |
311 | Linux-next has become an integral part of the kernel development process; |
312 | all patches merged during a given merge window should really have found | |
313 | their way into linux-next some time before the merge window opens. | |
314 | ||
75b02146 | 315 | |
f7c9fe4b MCC |
316 | Staging trees |
317 | ------------- | |
f830673f | 318 | |
5c050fb9 | 319 | The kernel source tree contains the drivers/staging/ directory, where |
f830673f AS |
320 | many sub-directories for drivers or filesystems that are on their way to |
321 | being added to the kernel tree live. They remain in drivers/staging while | |
322 | they still need more work; once complete, they can be moved into the | |
323 | kernel proper. This is a way to keep track of drivers that aren't | |
324 | up to Linux kernel coding or quality standards, but people may want to use | |
325 | them and track development. | |
326 | ||
5c050fb9 JC |
327 | Greg Kroah-Hartman currently maintains the staging tree. Drivers that |
328 | still need work are sent to him, with each driver having its own | |
329 | subdirectory in drivers/staging/. Along with the driver source files, a | |
330 | TODO file should be present in the directory as well. The TODO file lists | |
331 | the pending work that the driver needs for acceptance into the kernel | |
332 | proper, as well as a list of people that should be Cc'd for any patches to | |
333 | the driver. Current rules require that drivers contributed to staging | |
334 | must, at a minimum, compile properly. | |
335 | ||
336 | Staging can be a relatively easy way to get new drivers into the mainline | |
337 | where, with luck, they will come to the attention of other developers and | |
338 | improve quickly. Entry into staging is not the end of the story, though; | |
339 | code in staging which is not seeing regular progress will eventually be | |
340 | removed. Distributors also tend to be relatively reluctant to enable | |
341 | staging drivers. So staging is, at best, a stop on the way toward becoming | |
342 | a proper mainline driver. | |
343 | ||
75b02146 | 344 | |
f7c9fe4b MCC |
345 | Tools |
346 | ----- | |
75b02146 JC |
347 | |
348 | As can be seen from the above text, the kernel development process depends | |
349 | heavily on the ability to herd collections of patches in various | |
350 | directions. The whole thing would not work anywhere near as well as it | |
351 | does without suitably powerful tools. Tutorials on how to use these tools | |
352 | are well beyond the scope of this document, but there is space for a few | |
353 | pointers. | |
354 | ||
355 | By far the dominant source code management system used by the kernel | |
356 | community is git. Git is one of a number of distributed version control | |
357 | systems being developed in the free software community. It is well tuned | |
358 | for kernel development, in that it performs quite well when dealing with | |
359 | large repositories and large numbers of patches. It also has a reputation | |
360 | for being difficult to learn and use, though it has gotten better over | |
361 | time. Some sort of familiarity with git is almost a requirement for kernel | |
362 | developers; even if they do not use it for their own work, they'll need git | |
363 | to keep up with what other developers (and the mainline) are doing. | |
364 | ||
365 | Git is now packaged by almost all Linux distributions. There is a home | |
ef0eba47 | 366 | page at: |
75b02146 | 367 | |
e7b4311e | 368 | https://git-scm.com/ |
75b02146 | 369 | |
5c050fb9 | 370 | That page has pointers to documentation and tutorials. |
75b02146 JC |
371 | |
372 | Among the kernel developers who do not use git, the most popular choice is | |
373 | almost certainly Mercurial: | |
374 | ||
e7b4311e | 375 | https://www.selenic.com/mercurial/ |
75b02146 JC |
376 | |
377 | Mercurial shares many features with git, but it provides an interface which | |
378 | many find easier to use. | |
379 | ||
380 | The other tool worth knowing about is Quilt: | |
381 | ||
e7b4311e | 382 | https://savannah.nongnu.org/projects/quilt/ |
75b02146 JC |
383 | |
384 | Quilt is a patch management system, rather than a source code management | |
385 | system. It does not track history over time; it is, instead, oriented | |
386 | toward tracking a specific set of changes against an evolving code base. | |
387 | Some major subsystem maintainers use quilt to manage patches intended to go | |
388 | upstream. For the management of certain kinds of trees (-mm, for example), | |
389 | quilt is the best tool for the job. | |
390 | ||
391 | ||
f7c9fe4b MCC |
392 | Mailing lists |
393 | ------------- | |
75b02146 JC |
394 | |
395 | A great deal of Linux kernel development work is done by way of mailing | |
396 | lists. It is hard to be a fully-functioning member of the community | |
397 | without joining at least one list somewhere. But Linux mailing lists also | |
398 | represent a potential hazard to developers, who risk getting buried under a | |
399 | load of electronic mail, running afoul of the conventions used on the Linux | |
400 | lists, or both. | |
401 | ||
402 | Most kernel mailing lists are run on vger.kernel.org; the master list can | |
403 | be found at: | |
404 | ||
405 | http://vger.kernel.org/vger-lists.html | |
406 | ||
407 | There are lists hosted elsewhere, though; a number of them are at | |
408 | lists.redhat.com. | |
409 | ||
410 | The core mailing list for kernel development is, of course, linux-kernel. | |
411 | This list is an intimidating place to be; volume can reach 500 messages per | |
412 | day, the amount of noise is high, the conversation can be severely | |
413 | technical, and participants are not always concerned with showing a high | |
414 | degree of politeness. But there is no other place where the kernel | |
415 | development community comes together as a whole; developers who avoid this | |
416 | list will miss important information. | |
417 | ||
418 | There are a few hints which can help with linux-kernel survival: | |
419 | ||
420 | - Have the list delivered to a separate folder, rather than your main | |
421 | mailbox. One must be able to ignore the stream for sustained periods of | |
422 | time. | |
423 | ||
424 | - Do not try to follow every conversation - nobody else does. It is | |
425 | important to filter on both the topic of interest (though note that | |
426 | long-running conversations can drift away from the original subject | |
427 | without changing the email subject line) and the people who are | |
5c050fb9 | 428 | participating. |
75b02146 JC |
429 | |
430 | - Do not feed the trolls. If somebody is trying to stir up an angry | |
431 | response, ignore them. | |
432 | ||
433 | - When responding to linux-kernel email (or that on other lists) preserve | |
434 | the Cc: header for all involved. In the absence of a strong reason (such | |
435 | as an explicit request), you should never remove recipients. Always make | |
436 | sure that the person you are responding to is in the Cc: list. This | |
437 | convention also makes it unnecessary to explicitly ask to be copied on | |
438 | replies to your postings. | |
439 | ||
440 | - Search the list archives (and the net as a whole) before asking | |
441 | questions. Some developers can get impatient with people who clearly | |
442 | have not done their homework. | |
443 | ||
444 | - Avoid top-posting (the practice of putting your answer above the quoted | |
445 | text you are responding to). It makes your response harder to read and | |
446 | makes a poor impression. | |
447 | ||
448 | - Ask on the correct mailing list. Linux-kernel may be the general meeting | |
449 | point, but it is not the best place to find developers from all | |
450 | subsystems. | |
451 | ||
452 | The last point - finding the correct mailing list - is a common place for | |
453 | beginning developers to go wrong. Somebody who asks a networking-related | |
454 | question on linux-kernel will almost certainly receive a polite suggestion | |
455 | to ask on the netdev list instead, as that is the list frequented by most | |
456 | networking developers. Other lists exist for the SCSI, video4linux, IDE, | |
457 | filesystem, etc. subsystems. The best place to look for mailing lists is | |
458 | in the MAINTAINERS file packaged with the kernel source. | |
459 | ||
460 | ||
f7c9fe4b MCC |
461 | Getting started with Kernel development |
462 | --------------------------------------- | |
75b02146 JC |
463 | |
464 | Questions about how to get started with the kernel development process are | |
465 | common - from both individuals and companies. Equally common are missteps | |
466 | which make the beginning of the relationship harder than it has to be. | |
467 | ||
468 | Companies often look to hire well-known developers to get a development | |
469 | group started. This can, in fact, be an effective technique. But it also | |
470 | tends to be expensive and does not do much to grow the pool of experienced | |
471 | kernel developers. It is possible to bring in-house developers up to speed | |
472 | on Linux kernel development, given the investment of a bit of time. Taking | |
473 | this time can endow an employer with a group of developers who understand | |
474 | the kernel and the company both, and who can help to train others as well. | |
475 | Over the medium term, this is often the more profitable approach. | |
476 | ||
477 | Individual developers are often, understandably, at a loss for a place to | |
478 | start. Beginning with a large project can be intimidating; one often wants | |
479 | to test the waters with something smaller first. This is the point where | |
480 | some developers jump into the creation of patches fixing spelling errors or | |
481 | minor coding style issues. Unfortunately, such patches create a level of | |
482 | noise which is distracting for the development community as a whole, so, | |
483 | increasingly, they are looked down upon. New developers wishing to | |
484 | introduce themselves to the community will not get the sort of reception | |
485 | they wish for by these means. | |
486 | ||
487 | Andrew Morton gives this advice for aspiring kernel developers | |
488 | ||
f7c9fe4b MCC |
489 | :: |
490 | ||
75b02146 JC |
491 | The #1 project for all kernel beginners should surely be "make sure |
492 | that the kernel runs perfectly at all times on all machines which | |
493 | you can lay your hands on". Usually the way to do this is to work | |
494 | with others on getting things fixed up (this can require | |
495 | persistence!) but that's fine - it's a part of kernel development. | |
496 | ||
e7b4311e | 497 | (https://lwn.net/Articles/283982/). |
75b02146 JC |
498 | |
499 | In the absence of obvious problems to fix, developers are advised to look | |
500 | at the current lists of regressions and open bugs in general. There is | |
501 | never any shortage of issues in need of fixing; by addressing these issues, | |
502 | developers will gain experience with the process while, at the same time, | |
503 | building respect with the rest of the development community. |