Documentation/SubmittingPatches: discuss first then submit

This is something I've had in mind for some time.  I get enough
e-mails as-is, and I suspect the workflow to get list members
involved would work better if we get the discussion concluded on
the list first before patches hit my tree (even 'next').

Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index cd80148111a086ee873ff2a91f341dda40d334ea..790022373503f9ed0dc4cb4714af734cf0145faa 100644 (file)
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -34,9 +34,9 @@ Checklist (and a short version for the impatient):
        - if your name is not writable in ASCII, make sure that
          you send off a message in the correct encoding.
        - send the patch to the list (git@vger.kernel.org) and the
        - if your name is not writable in ASCII, make sure that
          you send off a message in the correct encoding.
        - send the patch to the list (git@vger.kernel.org) and the

-         maintainer (gitster@pobox.com). If you use
-         git-send-email(1), please test it first by sending
-         email to yourself.
+         maintainer (gitster@pobox.com) if (and only if) the patch
+         is ready for inclusion. If you use git-send-email(1),
+         please test it first by sending email to yourself.

 
 Long version:
 
 
 Long version:
 


@@ -162,7 +162,8 @@ Note that your maintainer does not necessarily read everything
 on the git mailing list.  If your patch is for discussion first,
 send it "To:" the mailing list, and optionally "cc:" him.  If it
 is trivially correct or after the list reached a consensus, send
 on the git mailing list.  If your patch is for discussion first,
 send it "To:" the mailing list, and optionally "cc:" him.  If it
 is trivially correct or after the list reached a consensus, send

-it "To:" the maintainer and optionally "cc:" the list.
+it "To:" the maintainer and optionally "cc:" the list for
+inclusion.

 
 Also note that your maintainer does not actively involve himself in
 maintaining what are in contrib/ hierarchy.  When you send fixes and
 
 Also note that your maintainer does not actively involve himself in
 maintaining what are in contrib/ hierarchy.  When you send fixes and