Re: [PATCH 2/3] SubmittingPatches: mention subsystems with dedicated repositories
Junio C Hamano writes: > Jason Holden writes: > >> Any reason to leave out the maintainers email addresses? > > Nothing particular, other than that I did not find anywhere in the > file that does not break the flow. I've prepared this on top of the previous three. The second hunk that updates "(4) Sending your patches." is the logical place to have this information. The other hunks are correcting minor mistakes that are not related. I think I'll squash them to the patch 3/3. Documentation/SubmittingPatches | 27 ++- 1 file changed, 18 insertions(+), 9 deletions(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index a7daad3..9e113d0 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -31,8 +31,9 @@ change is relevant to. these parts should be based on their trees. To find the tip of a topic branch, run "git log --first-parent -master..pu" and look for the merge commit. The second parent of this -commit is the tip of the topic branch. +master..pu" and look for merge commits. The second parent of these +commits are the tips of topic branches. + (1) Make separate commits for logically separate changes. @@ -70,6 +71,7 @@ changes do not trigger errors with the sample pre-commit hook shipped in templates/hooks--pre-commit. To help ensure this does not happen, run git diff --check on your changes before you commit. + (2) Describe your changes well. The first line of the commit message should be a short description (50 @@ -185,14 +187,20 @@ not a text/plain, it's something else. Send your patch with "To:" set to the mailing list, with "cc:" listing people who are involved in the area you are touching (the output from "git blame $path" and "git shortlog --no-merges $path" would help to -identify them), to solicit comments and reviews. After the list -reached a consensus that it is a good idea to apply the patch, re-send -it with "To:" set to the maintainer and "cc:" the list for inclusion. -Do not forget to add trailers such as "Acked-by:", "Reviewed-by:" and -"Tested-by:" after your "Signed-off-by:" line as necessary. +identify them), to solicit comments and reviews. + +After the list reached a consensus that it is a good idea to apply the +patch, re-send it with "To:" set to the maintainer [*1*] and "cc:" the +list [*2*] for inclusion. Do not forget to add trailers such as +"Acked-by:", "Reviewed-by:" and "Tested-by:" after your +"Signed-off-by:" line as necessary. + +[Addresses] + *1* The current maintainer: gits...@pobox.com + *2* The mailing list: git@vger.kernel.org -(4) Sign your work +(5) Sign your work To improve tracking of who did what, we've borrowed the "sign-off" procedure from the Linux kernel project on patches @@ -304,7 +312,8 @@ suggests to the contributors: even get them in a "on top of your change" patch form. (3) Polish, refine, and re-send to the list and the people who - spend their time to improve your patch. Go back to step (2). + spent their time to help improving your patch. Go back to + step (2) until step (4) happens. (4) The list forms consensus that the last round of your patch is good. Send it to the list and cc the maintainer. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] SubmittingPatches: mention subsystems with dedicated repositories
Jason Holden writes: > Any reason to leave out the maintainers email addresses? Nothing particular, other than that I did not find anywhere in the file that does not break the flow. > My only other suggestion for this series might be to augment the file with > a patch submittal example(s). I found the best example to be in > git-send-email's man page,... I'd feel better to avoid copying and pasting. If send-email has good examples, shouldn't it be sufficient to refer to them? > --- > Example of sending patches for a new feature: > > Create the patches: > $ git format-patch --cover-letter -M origin/master -o outgoing/ > $ edit outgoing/-* > > To send your completed patches for initial consideration: > $ git send-email outgoing/* -to git@vger.kernel.org -cc gits...@pobox.com This is ambiguous; it makes it look as if you are CC'ing the maintainer, but for the initial round, it is likely that you are sending it to me only because I have been involved in the area the patch touches. > To send your reviewed patches for inclusion: > $ git send-email outgoing/* -to gits...@pobox.com -cc git@vger.kernel.org This is fine, but we would probably want to see it CC'ed to people who reviewed the initial submission, too. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] SubmittingPatches: mention subsystems with dedicated repositories
On Tue, Jan 01, 2013 at 03:24:54PM -0800, Junio C Hamano wrote: > > > +Subsystems with dedicated maintainers > + > +Some parts of the system have dedicated maintainers with their own > +repositories. > + > + - git-gui/ comes from git-gui project, maintained by Pat Thoyts: > + > +git://repo.or.cz/git-gui.git > + > + - gitk-git/ comes from Paul Mackerras's gitk project: > + > +git://ozlabs.org/~paulus/gitk > + > + - po/ comes from the localization coordinator, Jiang Xin: > + > + https://github.com/git-l10n/git-po/ > + > +Patches to these parts should be based on their trees. > + > + > An ideal patch flow > Any reason to leave out the maintainers email addresses? If we add that, all the content of the MAINTAINERS file we had been discussing would then be in this file. My only other suggestion for this series might be to augment the file with a patch submittal example(s). I found the best example to be in git-send-email's man page, but maybe enumerate the example out for the most common workflows. Maybe something like: --- Example of sending patches for a new feature: Create the patches: $ git format-patch --cover-letter -M origin/master -o outgoing/ $ edit outgoing/-* To send your completed patches for initial consideration: $ git send-email outgoing/* -to git@vger.kernel.org -cc gits...@pobox.com To send your reviewed patches for inclusion: $ git send-email outgoing/* -to gits...@pobox.com -cc git@vger.kernel.org -Jason -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] SubmittingPatches: mention subsystems with dedicated repositories
These were only mentioned in periodical "A note from the maintainer" posting and not in the documentation suite. SubmittingPatches has a section to help contributors decide on what commit to base their changes, which is the most suitable place for this information. Signed-off-by: Junio C Hamano --- Documentation/SubmittingPatches | 24 1 file changed, 24 insertions(+) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index b9fd182..e810263 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -88,6 +88,10 @@ change is relevant to. wait until some of the dependent topics graduate to 'master', and rebase your work. + - Some parts of the system have dedicated maintainers with their own + repositories (see the section "Subsystems" below). Changes to + these parts should be based on their trees. + To find the tip of a topic branch, run "git log --first-parent master..pu" and look for the merge commit. The second parent of this commit is the tip of the topic branch. @@ -279,6 +283,26 @@ You can also create your own tag or use one that's in common usage such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:". +Subsystems with dedicated maintainers + +Some parts of the system have dedicated maintainers with their own +repositories. + + - git-gui/ comes from git-gui project, maintained by Pat Thoyts: + +git://repo.or.cz/git-gui.git + + - gitk-git/ comes from Paul Mackerras's gitk project: + +git://ozlabs.org/~paulus/gitk + + - po/ comes from the localization coordinator, Jiang Xin: + + https://github.com/git-l10n/git-po/ + +Patches to these parts should be based on their trees. + + An ideal patch flow Here is an ideal patch flow for this project the current maintainer -- 1.8.1.209.gc32ab23 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
