Lines Matching +full:long +full:- +full:term
14 ---------------
16 The kernel developers use a loosely time-based release process, with a new
53 be called 5.6-rc1. The -rc1 release is the signal that the time to
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
107 "stable team," currently Greg Kroah-Hartman. The stable team will release
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
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
141 The selection of a kernel for long-term support is purely a matter of a
143 are no known plans for long-term support for any specific upcoming
148 ------------------------
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
172 - Early review. Patches are posted to the relevant mailing list, and
177 - Wider review. When the patch is getting close to ready for mainline
178 inclusion, it should be accepted by a relevant subsystem maintainer -
181 subsystem tree and into the -next trees (described below). When the
186 - Please note that most maintainers also have day jobs, so merging
195 - Merging into the mainline. Eventually, a successful patch will be
200 - Stable release. The number of users potentially affected by the patch
203 - Long-term maintenance. While it is certainly possible for a developer
209 in the longer term.
217 -------------------------------
222 chosen by Linus himself. The kernel project has long since grown to a size
242 When the merge window opens, top-level maintainers will ask Linus to "pull"
253 etc. This chain of repositories can be arbitrarily long, though it rarely
255 those managing lower-level trees, this process is known as the "chain of
264 ----------
275 the interesting subsystem trees, but that would be a big and error-prone
278 The answer comes in the form of -next trees, where subsystem trees are
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
284 Beyond that, -mm contains a significant collection of patches which have
287 no designated subsystem tree. As a result, -mm operates as a sort of
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
292 development cycle, approximately 5-10% of the patches going into the
293 mainline get there via -mm.
295 The current -mm patch is available in the "mmotm" (-mm of the moment)
303 The primary tree for next-cycle patch merging is linux-next, maintained by
304 Stephen Rothwell. The linux-next tree is, by design, a snapshot of what
306 Linux-next trees are announced on the linux-kernel and linux-next mailing
311 Linux-next has become an integral part of the kernel development process;
313 their way into linux-next some time before the merge window opens.
317 -------------
320 many sub-directories for drivers or filesystems that are on their way to
327 Greg Kroah-Hartman currently maintains the staging tree. Drivers that
346 -----
368 https://git-scm.com/
388 upstream. For the management of certain kinds of trees (-mm, for example),
393 -------------
396 lists. It is hard to be a fully-functioning member of the community
405 http://vger.kernel.org/vger-lists.html
410 The core mailing list for kernel development is, of course, linux-kernel.
418 There are a few hints which can help with linux-kernel survival:
420 - Have the list delivered to a separate folder, rather than your main
424 - Do not try to follow every conversation - nobody else does. It is
426 long-running conversations can drift away from the original subject
430 - Do not feed the trolls. If somebody is trying to stir up an angry
433 - When responding to linux-kernel email (or that on other lists) preserve
440 - Search the list archives (and the net as a whole) before asking
444 - Avoid top-posting (the practice of putting your answer above the quoted
448 - Ask on the correct mailing list. Linux-kernel may be the general meeting
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
462 ---------------------------------------
465 common - from both individuals and companies. Equally common are missteps
468 Companies often look to hire well-known developers to get a development
471 kernel developers. It is possible to bring in-house developers up to speed
475 Over the medium term, this is often the more profitable approach.
495 persistence!) but that's fine - it's a part of kernel development.