1 files changed, 4 insertions, 4 deletions
diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process
index 97726eba6102..ae8127c1a780 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.
-2.4: STAGING TREES
+2.4: NEXT TREES
 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
 job.
-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

diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process index 97726eba6102..ae8127c1a780 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:
154	inclusion, it should be accepted by a relevant subsystem maintainer -	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	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	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	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	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	159	the discovery of any problems resulting from the integration of this
160	patch with work being done by others.	160	patch with work being done by others.
@@ -236,7 +236,7 @@ finding the right maintainer. Sending patches directly to Linus is not
236	normally the right way to go.	236	normally the right way to go.
237		237
238		238
239	2.4: STAGING TREES	239	2.4: NEXT TREES
240		240
241	The chain of subsystem trees guides the flow of patches into the kernel,	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	242	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
250	the interesting subsystem trees, but that would be a big and error-prone	250	the interesting subsystem trees, but that would be a big and error-prone
251	job.	251	job.
252		252
253	The answer comes in the form of staging trees, where subsystem trees are	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	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	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	256	started). The -mm tree integrates patches from a long list of subsystem
@@ -275,7 +275,7 @@ directory at:
275	Use of the MMOTM tree is likely to be a frustrating experience, though;	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.	276	there is a definite chance that it will not even compile.
277		277
278	The other staging tree, started more recently, is linux-next, maintained by	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	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.	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	281	Linux-next trees are announced on the linux-kernel and linux-next mailing