Lines Matching refs:into

34 community) is merged into the mainline kernel.  The bulk of changes for a
62 As fixes make their way into the mainline, the patch rate will slow over
103 fix a significant bug, and (2) already be merged into the mainline for the
132 Patches do not go directly from the developer's keyboard into the mainline
142 a patch gets into the kernel.  What follows below is an introduction which
163    subsystem tree and into the -next trees (described below).  When the
177  - Merging into the mainline.  Eventually, a successful patch will be
178    merged into the mainline repository managed by Linus Torvalds.  More
194 is to try to cut the process down to a single "merging into the mainline"
201 There is exactly one person who can merge patches into the mainline kernel
203 into the 2.6.38 kernel, only 112 (around 1.3%) were directly chosen by Linus
209 The kernel code base is logically broken down into a set of subsystems:
215 patch for inclusion into the mainline kernel.
226 Linus agrees, the stream of patches will flow up into his repository,
240 Clearly, in a system like this, getting patches into the kernel depends on
247 The chain of subsystem trees guides the flow of patches into the kernel,
270 patch into the mainline, it is likely to end up in -mm.  Miscellaneous
273 development cycle, approximately 5-10% of the patches going into the
294 their way into linux-next some time before the merge window opens.
302 they still need more work; once complete, they can be moved into the
311 the pending work that the driver needs for acceptance into the kernel
316 Staging can be a relatively easy way to get new drivers into the mainline
318 improve quickly.  Entry into staging is not the end of the story, though;
457 some developers jump into the creation of patches fixing spelling errors or