Mercurial > mplayer.hg

comparison DOCS/tech/patches.txt @ 12898:2054ffe13177

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
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!