Lines Matching refs:of
4 with relatively small numbers of users and developers involved. With a
6 course of one year, the kernel has since had to evolve a number of
7 processes to keep development happening smoothly. A solid understanding of
8 how the process works is required in order to be an effective part of it.
26 changesets with changes to several hundred thousand lines of code. 2.6 is
27 thus the leading edge of Linux kernel development; the kernel uses a
31 merging of patches for each release. At the beginning of each development
34 community) is merged into the mainline kernel. The bulk of changes for a
35 new development cycle (and all of the major changes) will be merged during
40 merge window do not come out of thin air; they have been collected, tested,
41 and staged ahead of time. How that process works will be described in
44 The merge window lasts for approximately two weeks. At the end of this
46 first of the "rc" kernels. For the kernel which is destined to be 2.6.40,
47 for example, the release which happens at the end of the merge window will
55 features outside of the merge window tend to get an unfriendly reception.
83 the stable release? The most significant metric used is the list of
91 release is made. In the real world, this kind of perfection is hard to
92 achieve; there are just too many variables in a project of this size.
94 worse; the pile of changes waiting for the next merge window will grow
96 kernels go out with a handful of known regressions though, hopefully, none
97 of them are serious.
100 "stable team," currently consisting of Greg Kroah-Hartman. The stable team
117 for a longer period. As of this writing, the current long term kernels
124 The selection of a kernel for long-term support is purely a matter of a
136 This process can happen quickly for minor fixes, or, in the case of large
138 comes from a lack of understanding of this process or from attempts to
141 In the hopes of reducing that frustration, this document will describe how
151 in the open if at all possible; it can save a lot of time redesigning
164 process works, this step leads to more extensive review of the patch and
165 the discovery of any problems resulting from the integration of this
182 - Stable release. The number of users potentially affected by the patch
186 to forget about code after merging it, that sort of behavior tends to
188 eliminates some of the maintenance burden, in that others will fix
193 One of the largest mistakes made by kernel developers (or their employers)
202 repository: Linus Torvalds. But, of the over 9,500 patches which went
206 way the kernel developers have addressed this growth is through the use of
207 a lieutenant system built around a chain of trust.
209 The kernel code base is logically broken down into a set of subsystems:
214 of the kernel they manage; they are the ones who will (usually) accept a
217 Subsystem maintainers each manage their own version of the kernel source
220 maintainers to track a list of patches, including authorship information
226 Linus agrees, the stream of patches will flow up into his repository,
227 becoming part of the mainline kernel. The amount of attention that Linus
235 etc. This chain of repositories can be arbitrarily long, though it rarely
237 those managing lower-level trees, this process is known as the "chain of
247 The chain of subsystem trees guides the flow of patches into the kernel,
249 at all of the patches which are being prepared for the next merge window?
253 patches which use the older form of that function. Reviewers and testers
254 want access to the changes in their integrated form before all of those
255 changes land in the mainline kernel. One could pull changes from all of
259 The answer comes in the form of -next trees, where subsystem trees are
260 collected for testing and review. The older of these trees, maintained by
262 started). The -mm tree integrates patches from a long list of subsystem
265 Beyond that, -mm contains a significant collection of patches which have
267 mailing list, or they may apply to a part of the kernel for which there is
268 no designated subsystem tree. As a result, -mm operates as a sort of
269 subsystem tree of last resort; if there is no other obvious path for a
273 development cycle, approximately 5-10% of the patches going into the
276 The current -mm patch is available in the "mmotm" (-mm of the moment)
281 Use of the MMOTM tree is likely to be a frustrating experience, though;
285 Stephen Rothwell. The linux-next tree is, by design, a snapshot of what
292 Linux-next has become an integral part of the kernel development process;
303 kernel proper. This is a way to keep track of drivers that aren't
312 proper, as well as a list of people that should be Cc'd for any patches to
317 where, with luck, they will come to the attention of other developers and
318 improve quickly. Entry into staging is not the end of the story, though;
328 heavily on the ability to herd collections of patches in various
331 are well beyond the scope of this document, but there is space for a few
335 community is git. Git is one of a number of distributed version control
338 large repositories and large numbers of patches. It also has a reputation
340 time. Some sort of familiarity with git is almost a requirement for kernel
365 toward tracking a specific set of changes against an evolving code base.
367 upstream. For the management of certain kinds of trees (-mm, for example),
373 A great deal of Linux kernel development work is done by way of mailing
374 lists. It is hard to be a fully-functioning member of the community
377 load of electronic mail, running afoul of the conventions used on the Linux
385 There are lists hosted elsewhere, though; a number of them are at
388 The core mailing list for kernel development is, of course, linux-kernel.
390 day, the amount of noise is high, the conversation can be severely
392 degree of politeness. But there is no other place where the kernel
399 mailbox. One must be able to ignore the stream for sustained periods of
403 important to filter on both the topic of interest (though note that
412 the Cc: header for all involved. In the absence of a strong reason (such
422 - Avoid top-posting (the practice of putting your answer above the quoted
443 which make the beginning of the relationship harder than it has to be.
447 tends to be expensive and does not do much to grow the pool of experienced
449 on Linux kernel development, given the investment of a bit of time. Taking
450 this time can endow an employer with a group of developers who understand
457 some developers jump into the creation of patches fixing spelling errors or
458 minor coding style issues. Unfortunately, such patches create a level of
461 introduce themselves to the community will not get the sort of reception
470 persistence!) but that's fine - it's a part of kernel development.
474 In the absence of obvious problems to fix, developers are advised to look
475 at the current lists of regressions and open bugs in general. There is
476 never any shortage of issues in need of fixing; by addressing these issues,
478 building respect with the rest of the development community.