Documentation/development-process: add info on maintainers
PATCH 1/2 Documentation/development-process: add info on maintainers
From: Randy Dunlap <[email protected]>
Add info on maintainers and persistent posting.
Update git home page.
Signed-off-by Randy Dunlap <[email protected]>
Cc Jonathan Corbet <[email protected]>
--- Documentation/development-process/2.Process | 15 ++++++++--- Documentation/development-process/7.AdvancedTopics | 2 - 2 files changed, 13 insertions(+), 4 deletions(-)
Documentation/development-process/2.Process +12 -3
@@ -151,7 +151,7 @@ The stages that a patch goes through are well. - 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 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
@@ -159,6 +159,15 @@ The stages that a patch goes through are the discovery of any problems resulting from the integration of this 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 & merging. + - Merging into the mainline. Eventually, a successful patch will be merged into the mainline repository managed by Linus Torvalds. More 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 f 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 -page at +page at: - http://git.or.cz/ + http://git-scm.com/ That page has pointers to documentation and tutorials. One should be aware, in particular, of the Kernel Hacker's Guide to git, which has
Documentation/development-process/7.AdvancedTopics +1 -1
@@ -25,7 +25,7 @@ long document in its own right. Instead fits into the kernel development process in particular. Developers who 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
Documentation/development-process/2.Process The stages that a patch goes through are · line 169
Quoted 8 lines · On Tue, 6 Apr 2010 16:17:05 -0700 Randy Dunlap <[email protected]> wrote:
+- Please note that most maintainers also have day jobs, so merging
Documentation/development-process/2.Process +7
-0+ 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 & merging.
I'd prefer to spell out "and" in that last line, being the sort of person that I am. Either way:
Acked-by Jonathan Corbet <[email protected]>
jon
Quoted 12 lines · On Tue, 6 Apr 2010 17:26:36 -0600 Jonathan Corbet wrote:
Documentation/development-process/2.Process The stages that a patch goes through are · line 169
Quoted 8 lines · On Tue, 6 Apr 2010 16:17:05 -0700 Randy Dunlap <[email protected]> wrote:
+- Please note that most maintainers also have day jobs, so merging
Documentation/development-process/2.Process +7
-0+ 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 & merging.
Quoted 4 lines
I'd prefer to spell out "and" in that last line, being the sort of person that I am. Either way:
Acked-by Jonathan Corbet <[email protected]>
OK, I'll change that. Thanks for looking.
---
~Randy