Lines Matching +full:required +full:- +full:for +full:- +full:hardware +full:- +full:jobs
11 how the process works is required in order to be an effective part of it.
14 ---------------
16 The kernel developers use a loosely time-based release process, with a new
36 merging of patches for each release. At the beginning of each development
39 community) is merged into the mainline kernel. The bulk of changes for a
49 The merge window lasts for approximately two weeks. At the end of this
51 first of the "rc" kernels. For the kernel which is destined to be 5.6,
52 for example, the release which happens at the end of the merge window will
53 be called 5.6-rc1. The -rc1 release is the signal that the time to
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
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
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
93 serious. For this reason, patches which cause regressions are looked upon
101 worse; the pile of changes waiting for the next merge window will grow
107 "stable team," currently Greg Kroah-Hartman. The stable team will release
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
129 for a longer period. Please refer to the following link for the list of active
134 The selection of a kernel for long-term support is purely a matter of a
136 are no known plans for long-term support for any specific upcoming
141 ------------------------
145 process designed to ensure that each patch is reviewed for quality and that
147 This process can happen quickly for minor fixes, or, in the case of large
148 and controversial changes, go on for years. Much developer frustration
159 - Design. This is where the real requirements for the patch - and the way
160 those requirements will be met - are laid out. Design work is often
165 - Early review. Patches are posted to the relevant mailing list, and
170 - Wider review. When the patch is getting close to ready for mainline
171 inclusion, it should be accepted by a relevant subsystem maintainer -
174 subsystem tree and into the -next trees (described below). When the
179 - Please note that most maintainers also have day jobs, so merging
186 and keep sending it for review and merging.
188 - Merging into the mainline. Eventually, a successful patch will be
193 - Stable release. The number of users potentially affected by the patch
196 - Long-term maintenance. While it is certainly possible for a developer
201 continue to take responsibility for the code if it is to remain useful
206 step. This approach invariably leads to frustration for everybody
210 -------------------------------
213 repository: Linus Torvalds. But, for example, of the over 9,500 patches
223 who has overall responsibility for the code within that subsystem. These
224 subsystem maintainers are the gatekeepers (in a loose way) for the portion
226 patch for inclusion into the mainline kernel.
235 When the merge window opens, top-level maintainers will ask Linus to "pull"
236 the patches they have selected for merging from their repositories. If
244 For example, the networking tree is built from patches which accumulated
248 those managing lower-level trees, this process is known as the "chain of
257 ----------
261 at all of the patches which are being prepared for the next merge window?
264 core kernel function prototype, for example, will conflict with any other
268 the interesting subsystem trees, but that would be a big and error-prone
271 The answer comes in the form of -next trees, where subsystem trees are
272 collected for testing and review. The older of these trees, maintained by
273 Andrew Morton, is called "-mm" (for memory management, which is how it got
274 started). The -mm tree integrates patches from a long list of subsystem
277 Beyond that, -mm contains a significant collection of patches which have
279 mailing list, or they may apply to a part of the kernel for which there is
280 no designated subsystem tree. As a result, -mm operates as a sort of
281 subsystem tree of last resort; if there is no other obvious path for a
282 patch into the mainline, it is likely to end up in -mm. Miscellaneous
283 patches which accumulate in -mm will eventually either be forwarded on to
285 development cycle, approximately 5-10% of the patches going into the
286 mainline get there via -mm.
288 The current -mm patch is available in the "mmotm" (-mm of the moment)
296 The primary tree for next-cycle patch merging is linux-next, maintained by
297 Stephen Rothwell. The linux-next tree is, by design, a snapshot of what
299 Linux-next trees are announced on the linux-kernel and linux-next mailing
304 Linux-next has become an integral part of the kernel development process;
306 their way into linux-next some time before the merge window opens.
310 -------------
313 many sub-directories for drivers or filesystems that are on their way to
320 Greg Kroah-Hartman currently maintains the staging tree. Drivers that
324 the pending work that the driver needs for acceptance into the kernel
325 proper, as well as a list of people that should be Cc'd for any patches to
339 -----
345 are well beyond the scope of this document, but there is space for a few
351 for kernel development, in that it performs quite well when dealing with
353 for being difficult to learn and use, though it has gotten better over
354 time. Some sort of familiarity with git is almost a requirement for kernel
355 developers; even if they do not use it for their own work, they'll need git
361 https://git-scm.com/
381 upstream. For the management of certain kinds of trees (-mm, for example),
382 quilt is the best tool for the job.
386 -------------
389 lists. It is hard to be a fully-functioning member of the community
398 http://vger.kernel.org/vger-lists.html
403 The core mailing list for kernel development is, of course, linux-kernel.
411 There are a few hints which can help with linux-kernel survival:
413 - Have the list delivered to a separate folder, rather than your main
414 mailbox. One must be able to ignore the stream for sustained periods of
417 - Do not try to follow every conversation - nobody else does. It is
419 long-running conversations can drift away from the original subject
423 - Do not feed the trolls. If somebody is trying to stir up an angry
426 - When responding to linux-kernel email (or that on other lists) preserve
427 the Cc: header for all involved. In the absence of a strong reason (such
433 - Search the list archives (and the net as a whole) before asking
437 - Use interleaved ("inline") replies, which makes your response easier to
438 read. (i.e. avoid top-posting -- the practice of putting your answer above
439 the quoted text you are responding to.) For more details, see
440 :ref:`Documentation/process/submitting-patches.rst <interleaved_replies>`.
442 - Ask on the correct mailing list. Linux-kernel may be the general meeting
446 The last point - finding the correct mailing list - is a common place for
447 beginning developers to go wrong. Somebody who asks a networking-related
448 question on linux-kernel will almost certainly receive a polite suggestion
450 networking developers. Other lists exist for the SCSI, video4linux, IDE,
451 filesystem, etc. subsystems. The best place to look for mailing lists is
456 ---------------------------------------
459 common - from both individuals and companies. Equally common are missteps
462 Companies often look to hire well-known developers to get a development
465 kernel developers. It is possible to bring in-house developers up to speed
471 Individual developers are often, understandably, at a loss for a place to
476 noise which is distracting for the development community as a whole, so,
479 they wish for by these means.
481 Andrew Morton gives this advice for aspiring kernel developers
485 The #1 project for all kernel beginners should surely be "make sure
489 persistence!) but that's fine - it's a part of kernel development.