Lines Matching +full:technical +full:- +full:articles
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
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 ------------------------
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
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
210 -------------------------------
235 When the merge window opens, top-level maintainers will ask Linus to "pull"
248 those managing lower-level trees, this process is known as the "chain of
257 ----------
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
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
280 no designated subsystem tree. As a result, -mm operates as a sort of
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
339 -----
361 https://git-scm.com/
381 upstream. For the management of certain kinds of trees (-mm, for example),
386 -------------
389 lists. It is hard to be a fully-functioning member of the community
403 The core mailing list for kernel development is, of course, linux-kernel.
406 technical, and participants are not always concerned with showing a high
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
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
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
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
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
489 persistence!) but that's fine - it's a part of kernel development.
491 (https://lwn.net/Articles/283982/).