|
2121
|
1 Sending patches:
|
|
|
2 ~~~~~~~~~~~~~~~~
|
|
6101
|
3 Note: We know these rules are hard, but it's hard to maintain such a
|
|
2121
|
4 big and complex project, so you should accept our rules. We have no
|
|
|
5 time for fixing buggy, broken or old patches!
|
|
|
6
|
|
6101
|
7 1. Always make patches for the CVS version.
|
|
2121
|
8 We do not accept patches for old versions or releases.
|
|
|
9
|
|
6101
|
10 2. Make unified diffs ('diff -Naur' or 'cvs diff -u').
|
|
2121
|
11
|
|
6101
|
12 3. Test the functionality of your patch. We'll *refuse* it if it breaks
|
|
2121
|
13 something, even if it extends other features!
|
|
|
14
|
|
6101
|
15 4. Read your patch. We'll *refuse* it if it changes indentation of the
|
|
|
16 code or if it does tab/space conversion or other cosmetical changes!
|
|
2121
|
17
|
|
6101
|
18 5. Comment parts that really need it (tricky side-effects etc).
|
|
|
19 Commenting trivial code not required. Comments must be English!
|
|
2121
|
20
|
|
|
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
|
|
6101
|
23 you want to be an mplayer developer, you'll get CVS write access.
|
|
2121
|
24
|
|
|
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
|
|
4202
|
27 bzip2 *only* if it's really big or if you know that your mailer messes
|
|
6101
|
28 up (reformats) text attachments).
|
|
4202
|
29 Subject line should be: '[PATCH] very short description of the patch'.
|
|
6101
|
30 In the mail, describe in a few sentences what you change and why.
|
|
4202
|
31 If you made independent changes, try to send them as separate patches.
|
|
2121
|
32
|
|
|
33 Thank you!
|
|
|
34
|
|
|
35 A'rpi
|
