Mercurial > mplayer.hg

comparison DOCS/tech/patches.txt @ 12812:d63e770baf9f

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