aboutsummaryrefslogtreecommitdiffhomepage
diff options
context:
space:
mode:
authorGravatar diego <diego@b3059339-0415-0410-9bf9-f77b7e298cf2>2004-07-26 23:48:30 +0000
committerGravatar diego <diego@b3059339-0415-0410-9bf9-f77b7e298cf2>2004-07-26 23:48:30 +0000
commit4bb6cb858d3186aba6be7978805c024ecfa8c343 (patch)
treefaa5982b7e23f09766e990645ed49e921073c547
parent3934b160a82913e18fe8f549191944b25bcd8bb3 (diff)
Wording/spelling suggestions by the Wanderer, merged sections about when to
send separate patches. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@12901 b3059339-0415-0410-9bf9-f77b7e298cf2
-rw-r--r--DOCS/tech/patches.txt17
1 files changed, 8 insertions, 9 deletions
diff --git a/DOCS/tech/patches.txt b/DOCS/tech/patches.txt
index b258889dac..428267e68b 100644
--- a/DOCS/tech/patches.txt
+++ b/DOCS/tech/patches.txt
@@ -26,7 +26,7 @@ that your patch will be included.
something, even if it extends other features!
4. Read your patch. We'll *refuse* it if it changes indentation of the
- code or if it does tab/space conversion or other cosmetical changes!
+ code or if it does tab/space conversion or other cosmetic changes!
NOTE: If you already wrote some code and did cosmetic changes, you can
use 'diff -uwbBE' to help you remove them. Don't forget to check the
@@ -46,7 +46,8 @@ that your patch will be included.
speak several languages you are of course welcome to update some of the
translations as well.
- 7. If your patch is very big, try splitting it into several self-contained
+ 7. If you make independent changes, try to send them as separate patches.
+ If your patch is very big, try splitting it into several self-contained
pieces. Each part can then be reviewed and committed separately.
8. Send your patch to the mplayer-dev-eng mailing list as a base64-encoded
@@ -67,26 +68,24 @@ that your patch will be included.
but unset the "Mail delivery" option so that you can post without getting
any mails.
Try to avoid uploading the patch to a web or FTP site, send it directly
- to the mailing list. The less steps it takes us to get at the patch the
+ to the mailing list. The fewer steps it takes us to get at the patch the
higher the likelihood for it to get reviewed and applied. If your patch
is so big you cannot send it by mail, try splitting it into pieces.
9. Give us a few days to react. We try to review patches as fast as possible,
- but unfortunately we are constantly overloaded with work, be it MPlayer
+ but unfortunately we are constantly overloaded with work, be it MPlayer-
related or from our day to day lives. If your patch seems to be ignored,
please resend it and mention that you got ignored. We are interested in
your work and will eventually either accept it or reject it with an
explanation of what we disliked about your patch.
-10. Do not immediately ask for CVS write access. If you contributed one or
+10. Do not immediately ask for CVS write access. If you have contributed one or
more nice, acceptable patches and they need maintaining or you want to
be an MPlayer developer, you'll get CVS write access.
-11. For consistency reasons all option names must use '-' instead of '_'.
+11. For consistency reasons, all option names must use '-' instead of '_'.
-12. If you made a nontrivial contribution and wish to be mentioned in the
+12. If you make a nontrivial contribution and wish to be mentioned in the
AUTHORS file, include that in your patch.
-13. If you made independent changes, try to send them as separate patches.
-
Thank you!