From c2851fe22084fa5115b73c68fde2f55997f298f6 Mon Sep 17 00:00:00 2001 From: diego Date: Mon, 26 Jul 2004 00:52:56 +0000 Subject: [PATCH] Explain how to handle big patches and why uploading patches is bad. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@12899 b3059339-0415-0410-9bf9-f77b7e298cf2 --- DOCS/tech/patches.txt | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/DOCS/tech/patches.txt b/DOCS/tech/patches.txt index d4850cf74d..b258889dac 100644 --- a/DOCS/tech/patches.txt +++ b/DOCS/tech/patches.txt @@ -28,7 +28,7 @@ that your patch will be included. 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! - NOTE: If you alread wrote some code and did cosmetic changes, you can + 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 patch to make sure diff didn't ignore some important change and remove any remaining cosmetics! @@ -46,7 +46,10 @@ that your patch will be included. speak several languages you are of course welcome to update some of the translations as well. - 7. Send your patch to the mplayer-dev-eng mailing list as a base64-encoded + 7. 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 attachment with the subject line: '[PATCH] very short description of the patch'. In the mail, describe in a few sentences what you change and why. @@ -61,24 +64,29 @@ that your patch will be included. the developers on the list. We want you to be available for discussing your code, you might be asked to make modifications before we accept it. Don't worry, mplayer-dev-eng is not high traffic and you can subscribe - with the nomail option if you do not wish to receive all the mails. + 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 + 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. - 8. Give us a few days to react. We try to review patches as fast as possible, + 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 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. - 9. Do not immediately ask for CVS write access. If you contributed one or +10. Do not immediately ask for CVS write access. If you 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. -10. For consistency reasons all option names must use '-' instead of '_'. +11. For consistency reasons all option names must use '-' instead of '_'. -11. If you made a nontrivial contribution and wish to be mentioned in the +12. If you made a nontrivial contribution and wish to be mentioned in the AUTHORS file, include that in your patch. -12. If you made independent changes, try to send them as separate patches. +13. If you made independent changes, try to send them as separate patches. Thank you!