forked from ~ljy/RK356X_SDK_RELEASE
kernel/Documentation/process/2.Process.rst
.. .. @@ -18,18 +18,18 @@ 18 18 release history looks like this: 19 19 20 20 ====== ================= 21 22 23 24 25 26 21 22 23 24 25 26 27 27 ====== ================= 28 28 29 30 31 32 29 30 31 32 33 33 rolling development model which is continually integrating major changes. 34 34 35 35 A relatively straightforward discipline is followed with regard to the .. .. @@ -48,9 +48,9 @@ 48 48 49 49 The merge window lasts for approximately two weeks. At the end of this 50 50 time, Linus Torvalds will declare that the window is closed and release the 51 51 52 52 for example, the release which happens at the end of the merge window will 53 53 54 54 merge new features has passed, and that the time to stabilize the next 55 55 kernel has begun. 56 56 .. .. @@ -67,22 +67,23 @@ 67 67 As fixes make their way into the mainline, the patch rate will slow over 68 68 time. Linus releases new -rc kernels about once a week; a normal series 69 69 will get up to somewhere between -rc6 and -rc9 before the kernel is 70 70 71 71 At that point the whole process starts over again. 72 72 73 74 73 74 75 75 76 76 ============== =============================== 77 78 79 80 81 82 83 84 85 77 78 79 80 81 82 83 84 85 86 86 87 ============== =============================== 87 88 88 89 How do the developers decide when to close the development cycle and create .. .. @@ -98,43 +99,44 @@ 98 99 achieve; there are just too many variables in a project of this size. 99 100 There comes a point where delaying the final release just makes the problem 100 101 worse; the pile of changes waiting for the next merge window will grow 101 102 102 103 kernels go out with a handful of known regressions though, hopefully, none 103 104 of them are serious. 104 105 105 106 Once a stable release is made, its ongoing maintenance is passed off to the 106 107 108 109 110 111 112 107 108 109 110 111 112 113 113 114 114 115 ============== =============================== 115 116 117 118 119 120 116 117 118 119 120 121 121 122 ... ... 122 123 123 124 ============== =============================== 124 125 125 126 126 127 127 128 Some kernels are designated "long term" kernels; they will receive support 128 129 for a longer period. As of this writing, the current long term kernels 129 130 and their maintainers are: 130 131 131 132 133 134 135 136 137 132 133 134 135 136 137 138 139 138 140 139 141 The selection of a kernel for long-term support is purely a matter of a 140 142 maintainer having the need and the time to maintain that release. There .. .. @@ -215,12 +217,12 @@ 215 217 ------------------------------- 216 218 217 219 There is exactly one person who can merge patches into the mainline kernel 218 219 220 221 222 223 220 221 222 223 224 225 224 226 225 227 The kernel code base is logically broken down into a set of subsystems: 226 228 networking, specific architecture support, memory management, video .. .. @@ -293,7 +295,7 @@ 293 295 The current -mm patch is available in the "mmotm" (-mm of the moment) 294 296 directory at: 295 297 296 298 297 299 298 300 Use of the MMOTM tree is likely to be a frustrating experience, though; 299 301 there is a definite chance that it will not even compile. .. .. @@ -304,7 +306,7 @@ 304 306 Linux-next trees are announced on the linux-kernel and linux-next mailing 305 307 lists when they are assembled; they can be downloaded from: 306 308 307 309 308 310 309 311 Linux-next has become an integral part of the kernel development process; 310 312 all patches merged during a given merge window should really have found .. .. @@ -363,21 +365,21 @@ 363 365 Git is now packaged by almost all Linux distributions. There is a home 364 366 page at: 365 367 366 368 367 369 368 370 That page has pointers to documentation and tutorials. 369 371 370 372 Among the kernel developers who do not use git, the most popular choice is 371 373 almost certainly Mercurial: 372 374 373 375 374 376 375 377 Mercurial shares many features with git, but it provides an interface which 376 378 many find easier to use. 377 379 378 380 The other tool worth knowing about is Quilt: 379 381 380 382 381 383 382 384 Quilt is a patch management system, rather than a source code management 383 385 system. It does not track history over time; it is, instead, oriented .. .. @@ -403,7 +405,7 @@ 403 405 http://vger.kernel.org/vger-lists.html 404 406 405 407 There are lists hosted elsewhere, though; a number of them are at 406 408 407 409 408 410 The core mailing list for kernel development is, of course, linux-kernel. 409 411 This list is an intimidating place to be; volume can reach 500 messages per .. .. @@ -492,7 +494,7 @@ 492 494 with others on getting things fixed up (this can require 493 495 persistence!) but that's fine - it's a part of kernel development. 494 496 495 497 496 498 497 499 In the absence of obvious problems to fix, developers are advised to look 498 500 at the current lists of regressions and open bugs in general. There is
