Lines Matching +full:loss +full:- +full:of +full:- +full:signal
7 with relatively small numbers of users and developers involved. With a
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.
14 ---------------
16 The kernel developers use a loosely time-based release process, with a new
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
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
40 new development cycle (and all of the major changes) will be merged during
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
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
60 features outside of the merge window tend to get an unfriendly reception.
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
90 the stable release? The most significant metric used is the list of
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.
101 worse; the pile of changes waiting for the next merge window will grow
103 kernels go out with a handful of known regressions though, hopefully, none
104 of them are serious.
107 "stable team," currently Greg Kroah-Hartman. The stable team will release
126 5.2.21 was the final stable update of the 5.2 release.
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
140 The lifecycle of a patch
141 ------------------------
147 This process can happen quickly for minor fixes, or, in the case of large
149 comes from a lack of understanding of this process or from attempts to
152 In the hopes of reducing that frustration, this document will describe how
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
162 in the open if at all possible; it can save a lot of time redesigning
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
175 process works, this step leads to more extensive review of the patch and
176 the discovery of any problems resulting from the integration of this
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
197 to forget about code after merging it, that sort of behavior tends to
199 eliminates some of the maintenance burden, in that others will fix
204 One of the largest mistakes made by kernel developers (or their employers)
210 -------------------------------
213 repository: Linus Torvalds. But, for example, of the over 9,500 patches
218 through the use of a lieutenant system built around a chain of trust.
220 The kernel code base is logically broken down into a set of subsystems:
225 of the kernel they manage; they are the ones who will (usually) accept a
228 Subsystem maintainers each manage their own version of the kernel source
231 maintainers to track a list of patches, including authorship information
235 When the merge window opens, top-level maintainers will ask Linus to "pull"
237 Linus agrees, the stream of patches will flow up into his repository,
238 becoming part of the mainline kernel. The amount of attention that Linus
246 etc. This chain of repositories can be arbitrarily long, though it rarely
248 those managing lower-level trees, this process is known as the "chain of
257 ----------
259 The chain of subsystem trees guides the flow of patches into the kernel,
261 at all of the patches which are being prepared for the next merge window?
265 patches which use the older form of that function. Reviewers and testers
266 want access to the changes in their integrated form before all of those
267 changes land in the mainline kernel. One could pull changes from all of
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)
293 Use of the MMOTM tree is likely to be a frustrating experience, though;
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
316 kernel proper. This is a way to keep track of drivers that aren't
320 Greg Kroah-Hartman currently maintains the staging tree. Drivers that
325 proper, as well as a list of people that should be Cc'd for any patches to
330 where, with luck, they will come to the attention of other developers and
331 improve quickly. Entry into staging is not the end of the story, though;
339 -----
342 heavily on the ability to herd collections of patches in various
345 are well beyond the scope of this document, but there is space for a few
349 community is git. Git is one of a number of distributed version control
352 large repositories and large numbers of patches. It also has a reputation
354 time. Some sort of familiarity with git is almost a requirement for kernel
361 https://git-scm.com/
379 toward tracking a specific set of changes against an evolving code base.
381 upstream. For the management of certain kinds of trees (-mm, for example),
386 -------------
388 A great deal of Linux kernel development work is done by way of mailing
389 lists. It is hard to be a fully-functioning member of the community
392 load of electronic mail, running afoul of the conventions used on the Linux
403 The core mailing list for kernel development is, of course, linux-kernel.
405 day, the amount of noise is high, the conversation can be severely
407 degree of politeness. But there is no other place where the 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
418 important to filter on both the topic of interest (though note that
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
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
460 which make the beginning of the relationship harder than it has to be.
462 Companies often look to hire well-known developers to get a development
464 tends to be expensive and does not do much to grow the pool of experienced
465 kernel developers. It is possible to bring in-house developers up to speed
466 on Linux kernel development, given the investment of a bit of time. Taking
467 this time can endow an employer with a group of developers who understand
471 Individual developers are often, understandably, at a loss for a place to
474 some developers jump into the creation of patches fixing spelling errors or
475 minor coding style issues. Unfortunately, such patches create a level of
478 introduce themselves to the community will not get the sort of reception
489 persistence!) but that's fine - it's a part of kernel development.
493 In the absence of obvious problems to fix, developers are advised to look
494 at the current lists of regressions and open bugs in general. There is
495 never any shortage of issues in need of fixing; by addressing these issues,
497 building respect with the rest of the development community.