diff options
Diffstat (limited to 'Documentation/development-process')
| -rw-r--r-- | Documentation/development-process/2.Process | 4 | ||||
| -rw-r--r-- | Documentation/development-process/4.Coding | 4 | ||||
| -rw-r--r-- | Documentation/development-process/5.Posting | 8 |
3 files changed, 8 insertions, 8 deletions
diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process index 4823577c650..2e0617936e8 100644 --- a/Documentation/development-process/2.Process +++ b/Documentation/development-process/2.Process @@ -276,7 +276,7 @@ mainline get there via -mm. The current -mm patch is available in the "mmotm" (-mm of the moment) directory at: - http://userweb.kernel.org/~akpm/mmotm/ + http://www.ozlabs.org/~akpm/mmotm/ Use of the MMOTM tree is likely to be a frustrating experience, though; there is a definite chance that it will not even compile. @@ -287,7 +287,7 @@ the mainline is expected to look like after the next merge window closes. Linux-next trees are announced on the linux-kernel and linux-next mailing lists when they are assembled; they can be downloaded from: - http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/ + http://www.kernel.org/pub/linux/kernel/next/ Some information about linux-next has been gathered at: diff --git a/Documentation/development-process/4.Coding b/Documentation/development-process/4.Coding index f3f1a469443..e3cb6a56653 100644 --- a/Documentation/development-process/4.Coding +++ b/Documentation/development-process/4.Coding @@ -244,7 +244,7 @@ testing purposes. In particular, you should turn on: - DEBUG_SLAB can find a variety of memory allocation and use errors; it should be used on most development kernels. - - DEBUG_SPINLOCK, DEBUG_SPINLOCK_SLEEP, and DEBUG_MUTEXES will find a + - DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP, and DEBUG_MUTEXES will find a number of common locking errors. There are quite a few other debugging options, some of which will be @@ -278,7 +278,7 @@ enabled, a configurable percentage of memory allocations will be made to fail; these failures can be restricted to a specific range of code. Running with fault injection enabled allows the programmer to see how the code responds when things go badly. See -Documentation/fault-injection/fault-injection.text for more information on +Documentation/fault-injection/fault-injection.txt for more information on how to use this facility. Other kinds of errors can be found with the "sparse" static analysis tool. diff --git a/Documentation/development-process/5.Posting b/Documentation/development-process/5.Posting index 903a2546f13..8a48c9b6286 100644 --- a/Documentation/development-process/5.Posting +++ b/Documentation/development-process/5.Posting @@ -271,10 +271,10 @@ copies should go to: the linux-kernel list. - If you are fixing a bug, think about whether the fix should go into the - next stable update. If so, stable@kernel.org should get a copy of the - patch. Also add a "Cc: stable@kernel.org" to the tags within the patch - itself; that will cause the stable team to get a notification when your - fix goes into the mainline. + next stable update. If so, stable@vger.kernel.org should get a copy of + the patch. Also add a "Cc: stable@vger.kernel.org" to the tags within + the patch itself; that will cause the stable team to get a notification + when your fix goes into the mainline. When selecting recipients for a patch, it is good to have an idea of who you think will eventually accept the patch and get it merged. While it |