mirrors/git
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Documentation/SubmittingPatches: discuss first then submit

Browse Source 
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>
This commit is contained in:
Junio C Hamano
2008-02-03 17:00:16 -08:00
parent 4e891acf67
commit 0b0599402d
1 changed files with 5 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
Documentation/SubmittingPatches
View File

@ -34,9 +34,9 @@ Checklist (and a short version for the impatient):
- if your name is not writable in ASCII, make sure that - if your name is not writable in ASCII, make sure that
you send off a message in the correct encoding. you send off a message in the correct encoding.
- send the patch to the list (git@vger.kernel.org) and the - send the patch to the list (git@vger.kernel.org) and the
maintainer (gitster@pobox.com). If you use maintainer (gitster@pobox.com) if (and only if) the patch
git-send-email(1), please test it first by sending is ready for inclusion. If you use git-send-email(1),
email to yourself. 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, on the git mailing list. If your patch is for discussion first,
send it "To:" the mailing list, and optionally "cc:" him. If it send it "To:" the mailing list, and optionally "cc:" him. If it
is trivially correct or after the list reached a consensus, send 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 Also note that your maintainer does not actively involve himself in
maintaining what are in contrib/ hierarchy. When you send fixes and maintaining what are in contrib/ hierarchy. When you send fixes and