Documentation/development-process: add maintainers and git info
Add info on maintainers and persistent posting. Update git home page. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
parent
0af76d950e
commit
ef0eba477e
|
@ -151,7 +151,7 @@ The stages that a patch goes through are, generally:
|
||||||
well.
|
well.
|
||||||
|
|
||||||
- Wider review. When the patch is getting close to ready for mainline
|
- Wider review. When the patch is getting close to ready for mainline
|
||||||
inclusion, it will 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 staging trees (described below). When the
|
||||||
|
@ -159,6 +159,15 @@ The stages that a patch goes through are, generally:
|
||||||
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.
|
||||||
|
|
||||||
|
- Please note that most maintainers also have day jobs, so merging
|
||||||
|
your patch may not be their highest priority. If your patch is
|
||||||
|
getting feedback about changes that are needed, you should either
|
||||||
|
make those changes or justify why they should not be made. If your
|
||||||
|
patch has no review complaints but is not being merged by its
|
||||||
|
appropriate subsystem or driver maintainer, you should be persistent
|
||||||
|
in updating the patch to the current kernel so that it applies cleanly
|
||||||
|
and keep sending it for review and merging.
|
||||||
|
|
||||||
- Merging into the mainline. Eventually, a successful patch will be
|
- Merging into the mainline. Eventually, a successful patch will be
|
||||||
merged into the mainline repository managed by Linus Torvalds. More
|
merged into the mainline repository managed by Linus Torvalds. More
|
||||||
comments and/or problems may surface at this time; it is important that
|
comments and/or problems may surface at this time; it is important that
|
||||||
|
@ -319,9 +328,9 @@ developers; even if they do not use it for their own work, they'll need git
|
||||||
to keep up with what other developers (and the mainline) are doing.
|
to keep up with what other developers (and the mainline) are doing.
|
||||||
|
|
||||||
Git is now packaged by almost all Linux distributions. There is a home
|
Git is now packaged by almost all Linux distributions. There is a home
|
||||||
page at
|
page at:
|
||||||
|
|
||||||
http://git.or.cz/
|
http://git-scm.com/
|
||||||
|
|
||||||
That page has pointers to documentation and tutorials. One should be
|
That page has pointers to documentation and tutorials. One should be
|
||||||
aware, in particular, of the Kernel Hacker's Guide to git, which has
|
aware, in particular, of the Kernel Hacker's Guide to git, which has
|
||||||
|
|
|
@ -25,7 +25,7 @@ long document in its own right. Instead, the focus here will be on how git
|
||||||
fits into the kernel development process in particular. Developers who
|
fits into the kernel development process in particular. Developers who
|
||||||
wish to come up to speed with git will find more information at:
|
wish to come up to speed with git will find more information at:
|
||||||
|
|
||||||
http://git.or.cz/
|
http://git-scm.com/
|
||||||
|
|
||||||
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
|
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue