Mercurial > mplayer.hg

comparison DOCS/tech/patches.txt @ 18360:d604c7f2baba

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
patches should be always created from root dir
author attila
date Sun, 30 Apr 2006 20:32:01 +0000
parents fd120874cdea
children e20114911d05
comparison
equal deleted inserted replaced
18359:fd120874cdea 18360:d604c7f2baba
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 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 22 diff easier to apply as it saves the step of changing to the correct
23 directory. 23 directory.
24 24
25 3. Test the functionality of your patch. We'll *refuse* it if it breaks 25 3. Patches shoud always be created from the project root directory.
26 This simplifies applying a patch without first searching for the
27 right directory.
28
29 4. Test the functionality of your patch. We'll *refuse* it if it breaks
26 something, even if it extends other features! 30 something, even if it extends other features!
27 31
28 4. Read your patch. We'll *refuse* it if it changes indentation of the 32 5. Read your patch. We'll *refuse* it if it changes indentation of the
29 code or if it does tab/space conversion or other cosmetic changes! 33 code or if it does tab/space conversion or other cosmetic changes!
30 34
31 NOTE: If you already wrote some code and did cosmetic changes, you can 35 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 36 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 37 patch to make sure diff didn't ignore some important change and remove
34 any remaining cosmetics! 38 any remaining cosmetics!
35 39
36 5. Comment parts that really need it (tricky side-effects etc). 40 6. Comment parts that really need it (tricky side-effects etc).
37 Always document string operations! Comment on what you are doing 41 Always document string operations! Comment on what you are doing
38 and why it is safe. This makes it easy to review and change your 42 and why it is safe. This makes it easy to review and change your
39 code if needed. Commenting trivial code not required. 43 code if needed. Commenting trivial code not required.
40 Comments must be English! 44 Comments must be English!
41 45
42 6. If you implement new features, add or change command line switches or 46 7. If you implement new features, add or change command line switches or
43 modify the behavior of existing features, please do not forget to also 47 modify the behavior of existing features, please do not forget to also
44 update the documentation. The documentation maintainers will assist you 48 update the documentation. The documentation maintainers will assist you
45 in doing this. Updating the English documentation is enough. If you 49 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 50 speak several languages you are of course welcome to update some of the
47 translations as well. 51 translations as well.
48 52
49 7. If you make independent changes, try to send them as separate patches 53 8. If you make independent changes, try to send them as separate patches
50 in separate mails. Likewise, if your patch is very big, try splitting 54 in separate mails. Likewise, if your patch is very big, try splitting
51 it into several self-contained pieces. Each part can then be reviewed 55 it into several self-contained pieces. Each part can then be reviewed
52 and committed separately. Logical units should stay together, though, 56 and committed separately. Logical units should stay together, though,
53 e.g. do not send a patch for every file you change. 57 e.g. do not send a patch for every file you change.
54 58
55 8. Send your patch to the mplayer-dev-eng mailing list as a base64-encoded 59 9. Send your patch to the mplayer-dev-eng mailing list as a base64-encoded
56 attachment with the subject line: 60 attachment with the subject line:
57 '[PATCH] very short description of the patch'. 61 '[PATCH] very short description of the patch'.
58 In the mail, describe in a few sentences what you change and why. 62 In the mail, describe in a few sentences what you change and why.
59 The subject line is very important if you do not want your patch to get 63 The subject line is very important if you do not want your patch to get
60 lost in the noise. We need the uppercase [PATCH] to be able to search 64 lost in the noise. We need the uppercase [PATCH] to be able to search
75 Do not upload the patch to a web or FTP site, send it directly to the 79 Do not upload the patch to a web or FTP site, send it directly to the
76 mailing list. The fewer steps it takes us to get at the patch the higher 80 mailing list. The fewer steps it takes us to get at the patch the higher
77 the likelihood for it to get reviewed and applied. If your patch is so 81 the likelihood for it to get reviewed and applied. If your patch is so
78 big you cannot send it by mail, try splitting it into smaller pieces. 82 big you cannot send it by mail, try splitting it into smaller pieces.
79 83
80 9. Give us a few days to react. We try to review patches as fast as possible, 84 10. Give us a few days to react. We try to review patches as fast as possible,
81 but unfortunately we are constantly overloaded with work, be it MPlayer- 85 but unfortunately we are constantly overloaded with work, be it MPlayer-
82 related or from our day to day lives. If your patch seems to be ignored, 86 related or from our day to day lives. If your patch seems to be ignored,
83 send a reminder asking for opinions as a reply to the original patch and 87 send a reminder asking for opinions as a reply to the original patch and
84 mention that you got ignored. We are interested in your work and will 88 mention that you got ignored. We are interested in your work and will
85 eventually either accept it or reject it with an explanation of what we 89 eventually either accept it or reject it with an explanation of what we
87 patch to make it acceptable. Implement them if you want to see your patch 91 patch to make it acceptable. Implement them if you want to see your patch
88 applied and send the update to the mailing list. Remember that updates and 92 applied and send the update to the mailing list. Remember that updates and
89 reminders must be sent as replies to the original patch to preserve proper 93 reminders must be sent as replies to the original patch to preserve proper
90 mail threading. 94 mail threading.
91 95
92 10. Do not immediately ask for CVS write access. If you have contributed one or 96 11. Do not immediately ask for CVS write access. If you have contributed one or
93 more nice, acceptable patches and they need maintaining or you want to 97 more nice, acceptable patches and they need maintaining or you want to
94 be an MPlayer developer, you'll get CVS write access. 98 be an MPlayer developer, you'll get CVS write access.
95 99
96 11. For consistency reasons, all option names must use '-' instead of '_'. 100 12. For consistency reasons, all option names must use '-' instead of '_'.
97 101
98 12. If you make a nontrivial contribution and wish to be mentioned in the 102 13. If you make a nontrivial contribution and wish to be mentioned in the
99 AUTHORS file, include that in your patch. 103 AUTHORS file, include that in your patch.
100 104
101 13. Do not use printf for console output, use our own mp_msg functions instead. 105 14. Do not use printf for console output, use our own mp_msg functions instead.
102 For the output to be translated (which includes all messages of level 106 For the output to be translated (which includes all messages of level
103 MSGL_HINT and below), put the strings in help/help_mp-en.h. If you change 107 MSGL_HINT and below), put the strings in help/help_mp-en.h. If you change
104 strings, remove the occurrences of these strings from the translations. 108 strings, remove the occurrences of these strings from the translations.
105 There may be (compilation) trouble if outdated translations remain in place 109 There may be (compilation) trouble if outdated translations remain in place
106 and translators will pick up changes more easily if they see a new message 110 and translators will pick up changes more easily if they see a new message
107 that has to be translated. 111 that has to be translated.
108 112
109 14. If you send a modified or updated version of you patch, always resend 113 15. If you send a modified or updated version of you patch, always resend
110 the complete patch. It is very time consuming and error prone to piece 114 the complete patch. It is very time consuming and error prone to piece
111 patches together that are distributed over several mails. 115 patches together that are distributed over several mails.
112 Please always resend patches as replies to the original mail to keep 116 Please always resend patches as replies to the original mail to keep
113 the thread with the discussion together. 117 the thread with the discussion together.
114 118