diff options
| author |  Junio C Hamano <gitster@pobox.com> | 2008-02-03 17:00:16 -0800 |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2008-02-05 00:39:03 -0800 |
| commit | 0b0599402d0e4354c60d192eb926f46577040a29 (patch) | |
| tree | 05396080bae47a8af3d591633486db350d6d394d | |
| parent | Documentation/SubmittingPatches: Instruct how to use [PATCH] Subject header (diff) | |
| download | tgif-0b0599402d0e4354c60d192eb926f46577040a29.tar.xz | |
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>
| -rw-r--r-- | Documentation/SubmittingPatches | 9 |
1 files changed, 5 insertions, 4 deletions
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index cd80148111..7900223735 100644 --- 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 - 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: @@ -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 -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 |