Mercurial > mplayer.hg
comparison DOCS/tech/patches.txt @ 12898:2054ffe13177
Explain how to handle big patches and why uploading patches is bad.
author | diego |
---|---|
date | Mon, 26 Jul 2004 00:52:56 +0000 |
parents | d63e770baf9f |
children | a5df08927328 |
comparison
equal
deleted
inserted
replaced
12897:9cceec65e536 | 12898:2054ffe13177 |
---|---|
26 something, even if it extends other features! | 26 something, even if it extends other features! |
27 | 27 |
28 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 |
29 code or if it does tab/space conversion or other cosmetical changes! | 29 code or if it does tab/space conversion or other cosmetical changes! |
30 | 30 |
31 NOTE: If you alread wrote some code and did cosmetic changes, you can | 31 NOTE: If you already wrote some code and did cosmetic changes, you can |
32 use 'diff -uwbBE' to help you remove them. Don't forget to check the | 32 use 'diff -uwbBE' to help you remove them. Don't forget to check the |
33 patch to make sure diff didn't ignore some important change and remove | 33 patch to make sure diff didn't ignore some important change and remove |
34 any remaining cosmetics! | 34 any remaining cosmetics! |
35 | 35 |
36 5. Comment parts that really need it (tricky side-effects etc). | 36 5. Comment parts that really need it (tricky side-effects etc). |
44 update the documentation. The documentation maintainers will assist you | 44 update the documentation. The documentation maintainers will assist you |
45 in doing this. Updating the English documentation is enough. If you | 45 in doing this. Updating the English documentation is enough. If you |
46 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 |
47 translations as well. | 47 translations as well. |
48 | 48 |
49 7. Send your patch to the mplayer-dev-eng mailing list as a base64-encoded | 49 7. If your patch is very big, try splitting it into several self-contained |
50 pieces. Each part can then be reviewed and committed separately. | |
51 | |
52 8. Send your patch to the mplayer-dev-eng mailing list as a base64-encoded | |
50 attachment with the subject line: | 53 attachment with the subject line: |
51 '[PATCH] very short description of the patch'. | 54 '[PATCH] very short description of the patch'. |
52 In the mail, describe in a few sentences what you change and why. | 55 In the mail, describe in a few sentences what you change and why. |
53 The subject line is very important if you do not want your patch to get | 56 The subject line is very important if you do not want your patch to get |
54 lost in the noise. We need the uppercase [PATCH] to be able to search | 57 lost in the noise. We need the uppercase [PATCH] to be able to search |
59 You have to subscribe to mplayer-dev-eng since we blocked postings from | 62 You have to subscribe to mplayer-dev-eng since we blocked postings from |
60 non-subscribers after spam problems and because patches get reviewed by | 63 non-subscribers after spam problems and because patches get reviewed by |
61 the developers on the list. We want you to be available for discussing | 64 the developers on the list. We want you to be available for discussing |
62 your code, you might be asked to make modifications before we accept it. | 65 your code, you might be asked to make modifications before we accept it. |
63 Don't worry, mplayer-dev-eng is not high traffic and you can subscribe | 66 Don't worry, mplayer-dev-eng is not high traffic and you can subscribe |
64 with the nomail option if you do not wish to receive all the mails. | 67 but unset the "Mail delivery" option so that you can post without getting |
68 any mails. | |
69 Try to avoid uploading the patch to a web or FTP site, send it directly | |
70 to the mailing list. The less steps it takes us to get at the patch the | |
71 higher the likelihood for it to get reviewed and applied. If your patch | |
72 is so big you cannot send it by mail, try splitting it into pieces. | |
65 | 73 |
66 8. Give us a few days to react. We try to review patches as fast as possible, | 74 9. Give us a few days to react. We try to review patches as fast as possible, |
67 but unfortunately we are constantly overloaded with work, be it MPlayer | 75 but unfortunately we are constantly overloaded with work, be it MPlayer |
68 related or from our day to day lives. If your patch seems to be ignored, | 76 related or from our day to day lives. If your patch seems to be ignored, |
69 please resend it and mention that you got ignored. We are interested in | 77 please resend it and mention that you got ignored. We are interested in |
70 your work and will eventually either accept it or reject it with an | 78 your work and will eventually either accept it or reject it with an |
71 explanation of what we disliked about your patch. | 79 explanation of what we disliked about your patch. |
72 | 80 |
73 9. Do not immediately ask for CVS write access. If you contributed one or | 81 10. Do not immediately ask for CVS write access. If you contributed one or |
74 more nice, acceptable patches and they need maintaining or you want to | 82 more nice, acceptable patches and they need maintaining or you want to |
75 be an MPlayer developer, you'll get CVS write access. | 83 be an MPlayer developer, you'll get CVS write access. |
76 | 84 |
77 10. For consistency reasons all option names must use '-' instead of '_'. | 85 11. For consistency reasons all option names must use '-' instead of '_'. |
78 | 86 |
79 11. If you made a nontrivial contribution and wish to be mentioned in the | 87 12. If you made a nontrivial contribution and wish to be mentioned in the |
80 AUTHORS file, include that in your patch. | 88 AUTHORS file, include that in your patch. |
81 | 89 |
82 12. If you made independent changes, try to send them as separate patches. | 90 13. If you made independent changes, try to send them as separate patches. |
83 | 91 |
84 Thank you! | 92 Thank you! |