Mercurial > mplayer.hg
comparison DOCS/tech/patches.txt @ 18360:d604c7f2baba
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 |