# HG changeset patch # User diego # Date 1087461798 0 # Node ID 0d9dec871b8390354aaa89b297bbf3c5e8adfdcc # Parent 39ea0995dcb1be59dcc268ad25c308e46c7b7cc1 cosmetic reformatting (preparation for upcoming changes) diff -r 39ea0995dcb1 -r 0d9dec871b83 DOCS/tech/patches.txt --- a/DOCS/tech/patches.txt Thu Jun 17 01:07:53 2004 +0000 +++ b/DOCS/tech/patches.txt Thu Jun 17 08:43:18 2004 +0000 @@ -7,64 +7,65 @@ outdated patches. The closer you follow our rules the higher is the probability that your patch will be included. -0. Do not send complete files. These need to be diffed by hand to see the - changes, which makes reviews harder and less likely to occur. Besides as - soon as one of the files changes, your version becomes harder to apply, - thus reducing its chances of being accepted. + 0. Do not send complete files. These need to be diffed by hand to see the + changes, which makes reviews harder and less likely to occur. Besides as + soon as one of the files changes, your version becomes harder to apply, + thus reducing its chances of being accepted. -1. Always make patches for the CVS version. The README describes how to check - out CVS and daily CVS snapshots are available from our download page. - We do not accept patches for releases or outdated CVS versions. + 1. Always make patches for the CVS version. The README describes how to check + out CVS and daily CVS snapshots are available from our download page. + We do not accept patches for releases or outdated CVS versions. -2. Make unified diffs ('diff -Naur' or 'cvs diff -u'). Unified diffs can easily - be applied with 'patch'. This is much harder with other diff types. + 2. Make unified diffs ('diff -Naur' or 'cvs diff -u'). Unified diffs can be + applied easily with 'patch'. This is much harder with other diff types. -3. Test the functionality of your patch. We'll *refuse* it if it breaks - something, even if it extends other features! + 3. Test the functionality of your patch. We'll *refuse* it if it breaks + 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! + 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 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! + NOTE: If you alread 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! -5. Comment parts that really need it (tricky side-effects etc). - Commenting trivial code not required. Comments must be English! + 5. Comment parts that really need it (tricky side-effects etc). + Commenting trivial code not required. Comments must be English! -6. If you implement new features, add or change command line switches or modify - the behavior of existing features, please do not forget to also update the - documentation. The documentation maintainers will assist you in doing this. - Updating the English documentation is enough. If you speak several languages - you are of course welcome to update some of the translations as well. + 6. If you implement new features, add or change command line switches or + modify the behavior of existing features, please do not forget to also + update the documentation. The documentation maintainers will assist you + in doing this. Updating the English documentation is enough. If you + 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 - attachment (use gzip or bzip2 *only* if it's bigger than 80k or if you know - that your mailer messes up (reformats) text attachments) with the subject - line: '[PATCH] very short description of the patch'. - In the mail, describe in a few sentences what you change and why. - If you made independent changes, try to send them as separate patches. - The subject line is very important if you do not want your patch to get - lost in the noise. We need the uppercase [PATCH] to be able to search - for unapplied patches, so please use it. - You have to subscribe to mplayer-dev-eng since we blocked postings from - non-subscribers after spam problems and because patches get reviewed by 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. + 7. Send your patch to the mplayer-dev-eng mailing list as a base64-encoded + attachment (use gzip or bzip2 *only* if it's bigger than 80k or if you + know that your mailer messes up (reformats) text attachments) with the + subject line: '[PATCH] very short description of the patch'. + In the mail, describe in a few sentences what you change and why. + If you made independent changes, try to send them as separate patches. + The subject line is very important if you do not want your patch to get + lost in the noise. We need the uppercase [PATCH] to be able to search + for unapplied patches, so please use it. + You have to subscribe to mplayer-dev-eng since we blocked postings from + non-subscribers after spam problems and because patches get reviewed by + 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. -8. 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 - what and why we disliked about your patch. + 8. 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 what and why we disliked about your patch. -9. 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. + 9. 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 '_'.