Mercurial > mplayer.hg

comparison DOCS/tech/patches.txt @ 6101:ff80fbfa06f5

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
corrections by Diego Biurrun <diego@biurrun.de>
author jaf
date Thu, 16 May 2002 09:00:59 +0000
parents 408302343afe
children 56cef6e35f51
comparison
equal deleted inserted replaced
6100:eb97c0729496 6101:ff80fbfa06f5
1 Sending patches: 1 Sending patches:
2 ~~~~~~~~~~~~~~~~ 2 ~~~~~~~~~~~~~~~~
3 Note: We know these rules are hard, but it's hard to maintain such 3 Note: We know these rules are hard, but it's hard to maintain such a
4 big and complex project, so you should accept our rules. We have no 4 big and complex project, so you should accept our rules. We have no
5 time for fixing buggy, broken or old patches! 5 time for fixing buggy, broken or old patches!
6 6
7 1. Always make patch for the CVS version. 7 1. Always make patches for the CVS version.
8 We do not accept patches for old versions or releases. 8 We do not accept patches for old versions or releases.
9 9
10 2. Make unified diffs ('diff -Naur' or 'cvs diff -u') 10 2. Make unified diffs ('diff -Naur' or 'cvs diff -u').
11 11
12 3. Test functionality of your patch. We'll *refuse* it if it breaks 12 3. Test the functionality of your patch. We'll *refuse* it if it breaks
13 something, even if it extends other features! 13 something, even if it extends other features!
14 14
15 4. Read your patch. We'll *refuse* it if it changes indent of the 15 4. Read your patch. We'll *refuse* it if it changes indentation of the
16 code or it does tab/space or other cosmetical changes! 16 code or if it does tab/space conversion or other cosmetical changes!
17 17
18 5. Comment parts what really needs it (has tricky side-effects etc). 18 5. Comment parts that really need it (tricky side-effects etc).
19 Commenting trivial code not requires. Comments must be english! 19 Commenting trivial code not required. Comments must be English!
20 20
21 6. Do not ask for CVS write access at first time. If you contributed 21 6. Do not ask for CVS write access at first time. If you contributed
22 1 or more nice, acceptable patches and they need maintaining or 22 1 or more nice, acceptable patches and they need maintaining or
23 you want to be mplayer developer, you'll get CVS write access. 23 you want to be an mplayer developer, you'll get CVS write access.
24 24
25 7. Subscribe to the mplayer-dev-eng list (don't worry, it's low traffic) 25 7. Subscribe to the mplayer-dev-eng list (don't worry, it's low traffic)
26 and send your patch there as base64-encoded attachment (use gzip or 26 and send your patch there as base64-encoded attachment (use gzip or
27 bzip2 *only* if it's really big or if you know that your mailer messes 27 bzip2 *only* if it's really big or if you know that your mailer messes
28 up (re-format) text attachments). 28 up (reformats) text attachments).
29 Subject line should be: '[PATCH] very short description of the patch'. 29 Subject line should be: '[PATCH] very short description of the patch'.
30 In the mail, describe in a few sentences what (and why) are the changes. 30 In the mail, describe in a few sentences what you change and why.
31 If you made independent changes, try to send them as separate patches. 31 If you made independent changes, try to send them as separate patches.
32 32
33 Thank you! 33 Thank you!
34 34
35 A'rpi 35 A'rpi