Mercurial > mplayer.hg
comparison DOCS/tech/patches.txt @ 12812:d63e770baf9f
Patches should be created from the root of the source directory, explanation
improved.
author | diego |
---|---|
date | Wed, 14 Jul 2004 01:11:14 +0000 |
parents | 4e0acc8d3622 |
children | 2054ffe13177 |
comparison
equal
deleted
inserted
replaced
12811:d5f8efddac6c | 12812:d63e770baf9f |
---|---|
16 out CVS and daily CVS snapshots are available from our download page. | 16 out CVS and daily CVS snapshots are available from our download page. |
17 We do not accept patches for releases or outdated CVS versions. | 17 We do not accept patches for releases or outdated CVS versions. |
18 | 18 |
19 2. Make unified diffs ('diff -Naur' or 'cvs diff -u'). Unified diffs can be | 19 2. Make unified diffs ('diff -Naur' or 'cvs diff -u'). Unified diffs can be |
20 applied easily with 'patch'. This is much harder with other diff types. | 20 applied easily with 'patch'. This is much harder with other diff types. |
21 Create the diff from the root of the MPlayer source tree, this makes the | |
22 diff easier to apply as it saves the step of changing to the correct | |
23 directory. | |
21 | 24 |
22 3. Test the functionality of your patch. We'll *refuse* it if it breaks | 25 3. Test the functionality of your patch. We'll *refuse* it if it breaks |
23 something, even if it extends other features! | 26 something, even if it extends other features! |
24 | 27 |
25 4. Read your patch. We'll *refuse* it if it changes indentation of the | 28 4. Read your patch. We'll *refuse* it if it changes indentation of the |
42 in doing this. Updating the English documentation is enough. If you | 45 in doing this. Updating the English documentation is enough. If you |
43 speak several languages you are of course welcome to update some of the | 46 speak several languages you are of course welcome to update some of the |
44 translations as well. | 47 translations as well. |
45 | 48 |
46 7. Send your patch to the mplayer-dev-eng mailing list as a base64-encoded | 49 7. Send your patch to the mplayer-dev-eng mailing list as a base64-encoded |
47 attachment (use gzip or bzip2 *only* if it's bigger than 80k or if you | 50 attachment with the subject line: |
48 know that your mailer messes up (reformats) text attachments) with the | 51 '[PATCH] very short description of the patch'. |
49 subject line: '[PATCH] very short description of the patch'. | |
50 In the mail, describe in a few sentences what you change and why. | 52 In the mail, describe in a few sentences what you change and why. |
51 If you made independent changes, try to send them as separate patches. | |
52 The subject line is very important if you do not want your patch to get | 53 The subject line is very important if you do not want your patch to get |
53 lost in the noise. We need the uppercase [PATCH] to be able to search | 54 lost in the noise. We need the uppercase [PATCH] to be able to search |
54 for unapplied patches, so please use it. | 55 for unapplied patches, so please use it. |
56 Do not compress your patch unless it is larger than 80k or if you know | |
57 that your mailer messes up (reformats) text attachments. It only makes | |
58 handling the patch more difficult. | |
55 You have to subscribe to mplayer-dev-eng since we blocked postings from | 59 You have to subscribe to mplayer-dev-eng since we blocked postings from |
56 non-subscribers after spam problems and because patches get reviewed by | 60 non-subscribers after spam problems and because patches get reviewed by |
57 the developers on the list. We want you to be available for discussing | 61 the developers on the list. We want you to be available for discussing |
58 your code, you might be asked to make modifications before we accept it. | 62 your code, you might be asked to make modifications before we accept it. |
59 Don't worry, mplayer-dev-eng is not high traffic and you can subscribe | 63 Don't worry, mplayer-dev-eng is not high traffic and you can subscribe |
62 8. Give us a few days to react. We try to review patches as fast as possible, | 66 8. Give us a few days to react. We try to review patches as fast as possible, |
63 but unfortunately we are constantly overloaded with work, be it MPlayer | 67 but unfortunately we are constantly overloaded with work, be it MPlayer |
64 related or from our day to day lives. If your patch seems to be ignored, | 68 related or from our day to day lives. If your patch seems to be ignored, |
65 please resend it and mention that you got ignored. We are interested in | 69 please resend it and mention that you got ignored. We are interested in |
66 your work and will eventually either accept it or reject it with an | 70 your work and will eventually either accept it or reject it with an |
67 explanation what and why we disliked about your patch. | 71 explanation of what we disliked about your patch. |
68 | 72 |
69 9. Do not immediately ask for CVS write access. If you contributed one or | 73 9. Do not immediately ask for CVS write access. If you contributed one or |
70 more nice, acceptable patches and they need maintaining or you want to | 74 more nice, acceptable patches and they need maintaining or you want to |
71 be an MPlayer developer, you'll get CVS write access. | 75 be an MPlayer developer, you'll get CVS write access. |
72 | 76 |
73 10. For consistency reasons all option names must use '-' instead of '_'. | 77 10. For consistency reasons all option names must use '-' instead of '_'. |
74 | 78 |
75 11. If you made a nontrivial contribution and wish to be mentioned in the | 79 11. If you made a nontrivial contribution and wish to be mentioned in the |
76 AUTHORS file, include that in your patch. | 80 AUTHORS file, include that in your patch. |
77 | 81 |
78 12. Do not compress your patch unless it is very large. It only makes handling | 82 12. If you made independent changes, try to send them as separate patches. |
79 the patch more difficult. | |
80 | 83 |
81 Thank you! | 84 Thank you! |