path: root/Documentation/development-process
diff options
authorAndres Salomon <dilinger@queued.net>2010-11-18 12:27:35 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2010-11-18 15:00:47 -0800
commite4fabad30eaba5bb78cd8d47885f1b705a0918a0 (patch)
tree8a57ebc9fa325d9189ea8a82dbfb158761afba89 /Documentation/development-process
parentf99e0e98f95bbe8833bd96c314b71ef859851bc5 (diff)
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>
Diffstat (limited to 'Documentation/development-process')
1 files changed, 4 insertions, 4 deletions
diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process
index 97726eba610..ae8127c1a78 100644
--- a/Documentation/development-process/2.Process
+++ b/Documentation/development-process/2.Process
@@ -154,7 +154,7 @@ The stages that a patch goes through are, generally:
inclusion, it should be accepted by a relevant subsystem maintainer -
though this acceptance is not a guarantee that the patch will make it
all the way to the mainline. The patch will show up in the maintainer's
- subsystem tree and into the staging trees (described below). When the
+ subsystem tree and into the -next trees (described below). When the
process works, this step leads to more extensive review of the patch and
the discovery of any problems resulting from the integration of this
patch with work being done by others.
@@ -236,7 +236,7 @@ finding the right maintainer. Sending patches directly to Linus is not
normally the right way to go.
The chain of subsystem trees guides the flow of patches into the kernel,
but it also raises an interesting question: what if somebody wants to look
@@ -250,7 +250,7 @@ changes land in the mainline kernel. One could pull changes from all of
the interesting subsystem trees, but that would be a big and error-prone
-The answer comes in the form of staging trees, where subsystem trees are
+The answer comes in the form of -next trees, where subsystem trees are
collected for testing and review. The older of these trees, maintained by
Andrew Morton, is called "-mm" (for memory management, which is how it got
started). The -mm tree integrates patches from a long list of subsystem
@@ -275,7 +275,7 @@ directory at:
Use of the MMOTM tree is likely to be a frustrating experience, though;
there is a definite chance that it will not even compile.
-The other staging tree, started more recently, is linux-next, maintained by
+The other -next tree, started more recently, is linux-next, maintained by
Stephen Rothwell. The linux-next tree is, by design, a snapshot of what
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