Send patches - preferably formatted by git format-patch - to patches at archlinux32 dot org.
summaryrefslogtreecommitdiff
path: root/doc/submitting-patches.txt
diff options
context:
space:
mode:
authorJason St. John <jstjohn@purdue.edu>2014-08-07 00:43:20 -0400
committerAllan McRae <allan@archlinux.org>2014-08-09 14:18:59 +1000
commitab07dfdeb9b4ecc443aa25f40fa530a730f65cde (patch)
tree58b27c50353f9eb540c6b7a3d6d05cf80b024f67 /doc/submitting-patches.txt
parent37634d22e501538e5a4b12105a0b56542841e71f (diff)
man: Improve grammar and add missing single quotes around command options
Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Allan McRae <allan@archlinux.org>
Diffstat (limited to 'doc/submitting-patches.txt')
-rw-r--r--doc/submitting-patches.txt14
1 files changed, 7 insertions, 7 deletions
diff --git a/doc/submitting-patches.txt b/doc/submitting-patches.txt
index 7c61dd18..77ec771f 100644
--- a/doc/submitting-patches.txt
+++ b/doc/submitting-patches.txt
@@ -60,7 +60,7 @@ Submitting your patch
* Send the patch to the pacman-dev mailing list
The mailing list is the primary queue for review and acceptance. Here you
-will get feedback, and let me know the details of your patch.
+will get feedback, and let the reviewers know the details of your patch.
* No MIME, no links, no compression, no attachments. Just plain text.
@@ -69,9 +69,9 @@ reasons for this. First, it makes them easier to read with any mail reader,
it allows easier review "at a glance", and most importantly, it allows people
to comment on exact lines of the patch in reply emails.
-`git send-email` allows you to send git formatted patches in plain text easily
+`git send-email` allows you to send Git-formatted patches in plain text easily
and is the preferred method for submission to the mailing list. Mail clients,
-including gmail's web interface, have a tendency to break patches by wrapping
+including Gmail's web interface, have a tendency to break patches by wrapping
lines and/or adjusting whitespace and should be avoided.
--
@@ -92,11 +92,11 @@ looked at it yet.
* Respond to feedback
When you do get feedback, it usually merits a response, whether this be a
-resubmit of the patch with corrections or a follow-up email asking for
-clarifications. When neither of these occurs, don't expect your patch to see
+resubmission of the patch with corrections or a follow-up email asking for
+clarifications. When neither of these occurs, don't expect your patch to get
further review. The all-volunteer staff don't have time to fix up patches that
-aren't their own. When resubmitting patches update the subject line to reflect
-the version number ('[PATCHv2]') and send it as a reply to the original thread.
+aren't their own. When resubmitting patches, update the subject line to reflect
+the version number ('[PATCHv2]'), and send it as a reply to the original thread.
--