Documentation/development-process: use -next trees instead of staging

This is confusing, as we have "staging" trees for drivers/staging. Call
them -next trees.

Signed-off-by: Andres Salomon <dilinger@queued.net>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

authored by Andres Salomon and committed by Linus Torvalds e4fabad3 f99e0e98

+4 -4
+4 -4
Documentation/development-process/2.Process
··· 154 inclusion, it should be accepted by a relevant subsystem maintainer - 155 though this acceptance is not a guarantee that the patch will make it 156 all the way to the mainline. The patch will show up in the maintainer's 157 - subsystem tree and into the staging trees (described below). When the 158 process works, this step leads to more extensive review of the patch and 159 the discovery of any problems resulting from the integration of this 160 patch with work being done by others. ··· 236 normally the right way to go. 237 238 239 - 2.4: STAGING TREES 240 241 The chain of subsystem trees guides the flow of patches into the kernel, 242 but it also raises an interesting question: what if somebody wants to look ··· 250 the interesting subsystem trees, but that would be a big and error-prone 251 job. 252 253 - The answer comes in the form of staging trees, where subsystem trees are 254 collected for testing and review. The older of these trees, maintained by 255 Andrew Morton, is called "-mm" (for memory management, which is how it got 256 started). The -mm tree integrates patches from a long list of subsystem ··· 275 Use of the MMOTM tree is likely to be a frustrating experience, though; 276 there is a definite chance that it will not even compile. 277 278 - The other staging tree, started more recently, is linux-next, maintained by 279 Stephen Rothwell. The linux-next tree is, by design, a snapshot of what 280 the mainline is expected to look like after the next merge window closes. 281 Linux-next trees are announced on the linux-kernel and linux-next mailing
··· 154 inclusion, it should be accepted by a relevant subsystem maintainer - 155 though this acceptance is not a guarantee that the patch will make it 156 all the way to the mainline. The patch will show up in the maintainer's 157 + subsystem tree and into the -next trees (described below). When the 158 process works, this step leads to more extensive review of the patch and 159 the discovery of any problems resulting from the integration of this 160 patch with work being done by others. ··· 236 normally the right way to go. 237 238 239 + 2.4: NEXT TREES 240 241 The chain of subsystem trees guides the flow of patches into the kernel, 242 but it also raises an interesting question: what if somebody wants to look ··· 250 the interesting subsystem trees, but that would be a big and error-prone 251 job. 252 253 + The answer comes in the form of -next trees, where subsystem trees are 254 collected for testing and review. The older of these trees, maintained by 255 Andrew Morton, is called "-mm" (for memory management, which is how it got 256 started). The -mm tree integrates patches from a long list of subsystem ··· 275 Use of the MMOTM tree is likely to be a frustrating experience, though; 276 there is a definite chance that it will not even compile. 277 278 + The other -next tree, started more recently, is linux-next, maintained by 279 Stephen Rothwell. The linux-next tree is, by design, a snapshot of what 280 the mainline is expected to look like after the next merge window closes. 281 Linux-next trees are announced on the linux-kernel and linux-next mailing