Lines Matching +full:2 +full:- +full:way
8 user base in the millions and with some 2,000 developers involved over the
14 ---------------
16 The kernel developers use a loosely time-based release process, with a new
22 4.12 July 2, 2017
53 be called 2.6.40-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
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
78 February 11 4.16-rc1, merge window closes
79 February 18 4.16-rc2
80 February 25 4.16-rc3
81 March 4 4.16-rc4
82 March 11 4.16-rc5
83 March 18 4.16-rc6
84 March 25 4.16-rc7
106 "stable team," currently consisting of Greg Kroah-Hartman. The stable team
109 fix a significant bug, and (2) already be merged into the mainline for the
117 September 20 4.13.2
132 3.16 Ben Hutchings (very long-term stable kernel)
134 4.4 Greg Kroah-Hartman (very long-term stable kernel)
135 4.9 Greg Kroah-Hartman
136 4.14 Greg Kroah-Hartman
139 The selection of a kernel for long-term support is purely a matter of a
141 are no known plans for long-term support for any specific upcoming
146 ------------------------
159 describes the process in a somewhat idealized way. A much more detailed
164 - Design. This is where the real requirements for the patch - and the way
165 those requirements will be met - are laid out. Design work is often
170 - Early review. Patches are posted to the relevant mailing list, and
175 - Wider review. When the patch is getting close to ready for mainline
176 inclusion, it should be accepted by a relevant subsystem maintainer -
178 all the way to the mainline. The patch will show up in the maintainer's
179 subsystem tree and into the -next trees (described below). When the
184 - Please note that most maintainers also have day jobs, so merging
193 - Merging into the mainline. Eventually, a successful patch will be
198 - Stable release. The number of users potentially affected by the patch
201 - Long-term maintenance. While it is certainly possible for a developer
215 -------------------------------
222 way the kernel developers have addressed this growth is through the use of
229 subsystem maintainers are the gatekeepers (in a loose way) for the portion
240 When the merge window opens, top-level maintainers will ask Linus to "pull"
253 those managing lower-level trees, this process is known as the "chain of
258 normally the right way to go.
262 ----------
273 the interesting subsystem trees, but that would be a big and error-prone
276 The answer comes in the form of -next trees, where subsystem trees are
278 Andrew Morton, is called "-mm" (for memory management, which is how it got
279 started). The -mm tree integrates patches from a long list of subsystem
282 Beyond that, -mm contains a significant collection of patches which have
285 no designated subsystem tree. As a result, -mm operates as a sort of
287 patch into the mainline, it is likely to end up in -mm. Miscellaneous
288 patches which accumulate in -mm will eventually either be forwarded on to
290 development cycle, approximately 5-10% of the patches going into the
291 mainline get there via -mm.
293 The current -mm patch is available in the "mmotm" (-mm of the moment)
301 The primary tree for next-cycle patch merging is linux-next, maintained by
302 Stephen Rothwell. The linux-next tree is, by design, a snapshot of what
304 Linux-next trees are announced on the linux-kernel and linux-next mailing
309 Linux-next has become an integral part of the kernel development process;
311 their way into linux-next some time before the merge window opens.
315 -------------
318 many sub-directories for drivers or filesystems that are on their way to
321 kernel proper. This is a way to keep track of drivers that aren't
325 Greg Kroah-Hartman currently maintains the staging tree. Drivers that
334 Staging can be a relatively easy way to get new drivers into the mainline
339 staging drivers. So staging is, at best, a stop on the way toward becoming
344 -----
366 http://git-scm.com/
386 upstream. For the management of certain kinds of trees (-mm, for example),
391 -------------
393 A great deal of Linux kernel development work is done by way of mailing
394 lists. It is hard to be a fully-functioning member of the community
403 http://vger.kernel.org/vger-lists.html
408 The core mailing list for kernel development is, of course, linux-kernel.
416 There are a few hints which can help with linux-kernel survival:
418 - Have the list delivered to a separate folder, rather than your main
422 - Do not try to follow every conversation - nobody else does. It is
424 long-running conversations can drift away from the original subject
428 - Do not feed the trolls. If somebody is trying to stir up an angry
431 - When responding to linux-kernel email (or that on other lists) preserve
438 - Search the list archives (and the net as a whole) before asking
442 - Avoid top-posting (the practice of putting your answer above the quoted
446 - Ask on the correct mailing list. Linux-kernel may be the general meeting
450 The last point - finding the correct mailing list - is a common place for
451 beginning developers to go wrong. Somebody who asks a networking-related
452 question on linux-kernel will almost certainly receive a polite suggestion
460 ---------------------------------------
463 common - from both individuals and companies. Equally common are missteps
466 Companies often look to hire well-known developers to get a development
469 kernel developers. It is possible to bring in-house developers up to speed
491 you can lay your hands on". Usually the way to do this is to work
493 persistence!) but that's fine - it's a part of kernel development.