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>
This commit is contained in:
committed by
Linus Torvalds
parent
f99e0e98f9
commit
e4fabad30e
@@ -154,7 +154,7 @@ The stages that a patch goes through are, generally:
|
|||||||
inclusion, it should be accepted by a relevant subsystem maintainer -
|
inclusion, it should be accepted by a relevant subsystem maintainer -
|
||||||
though this acceptance is not a guarantee that the patch will make it
|
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
|
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
|
process works, this step leads to more extensive review of the patch and
|
||||||
the discovery of any problems resulting from the integration of this
|
the discovery of any problems resulting from the integration of this
|
||||||
patch with work being done by others.
|
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.
|
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,
|
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
|
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 interesting subsystem trees, but that would be a big and error-prone
|
||||||
job.
|
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
|
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
|
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
|
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;
|
Use of the MMOTM tree is likely to be a frustrating experience, though;
|
||||||
there is a definite chance that it will not even compile.
|
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
|
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.
|
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
|
Linux-next trees are announced on the linux-kernel and linux-next mailing
|
||||||
|
Reference in New Issue
Block a user