diff options
Diffstat (limited to 'DOCS/tech/patches.txt')
| -rw-r--r-- | DOCS/tech/patches.txt | 119 |
1 files changed, 0 insertions, 119 deletions
diff --git a/DOCS/tech/patches.txt b/DOCS/tech/patches.txt deleted file mode 100644 index dfff16bf85..0000000000 --- a/DOCS/tech/patches.txt +++ /dev/null @@ -1,119 +0,0 @@ -Sending patches: -~~~~~~~~~~~~~~~~ - -Note: We know our rules place a burden on you, but rest assured that -maintaining a big and complex software project is even harder, so please -accept our rules. We cannot afford to spend our time fixing buggy, broken or -outdated patches. The closer you follow our rules the higher is the probability -that your patch will be included. - - 0. Do not send complete files. These need to be diffed by hand to see the - changes, which makes reviews harder and less likely to occur. Besides as - soon as one of the files changes, your version becomes harder to apply, - thus reducing its chances of being accepted. - - 1. Always make patches for Subversion HEAD. The README describes how to check - out Subversion and daily snapshots are available from our download page. - We do not accept patches for releases or outdated Subversion revisions. - - 2. Make unified diffs ('svn diff' or 'diff -Naur'). Unified diffs can be - applied easily with 'patch'. This is much harder with other diff types. - Besides, unified diffs are more readable and thus easier to review. - - 3. Create the diff from the root of the MPlayer source tree, this makes the - diff easier to apply as it saves the step of searching for and changing - to the correct directory. - - 4. Test the functionality of your patch. We'll *refuse* it if it breaks - something, even if it extends other features! - - 5. Read your patch. We'll *refuse* it if it changes indentation of the - code or if it does tab/space conversion or other cosmetic changes! - - NOTE: If you already wrote some code and did cosmetic changes, you can - use 'diff -uwbBE' to help you remove them. Don't forget to check the - patch to make sure diff didn't ignore some important change and remove - any remaining cosmetics! - To use these options directly with svn, use this command: - svn diff --diff-cmd diff -x -uwbBE - - 6. Comment parts that really need it (tricky side-effects etc). - Always document string operations! Comment on what you are doing - and why it is safe. This makes it easy to review and change your - code if needed. Commenting trivial code not required. - Comments must be English! - - 7. If you implement new features, add or change command line switches or - modify the behavior of existing features, please do not forget to also - update the documentation. The documentation maintainers will assist you - in doing this. Updating the English documentation is enough. If you - speak several languages you are of course welcome to update some of the - translations as well. - - 8. If you make independent changes, try to send them as separate patches - in separate mails. Likewise, if your patch is very big, try splitting - it into several self-contained pieces. Each part can then be reviewed - and committed separately. Logical units should stay together, though, - i.e. do not send a patch for every file or directory you change. - - 9. Send your patch to the mplayer-dev-eng mailing list as attachment with - the subject line: - '[PATCH] very short description of the patch'. - In the mail, describe in a few sentences what you change and why. - The subject line is very important if you do not want your patch to get - lost in the noise. We need the uppercase [PATCH] to be able to search - for unapplied patches, so please use it. - Do not send your patch as a reply to some other unrelated mail, compose - a new message, otherwise it will probably get overlooked. - Do not compress your patch unless it is larger than 80k or if you know - that your mailer messes up (reformats) text attachments. It only makes - handling the patch more difficult. If you have to compress your patch, - use either bzip2, gzip or zip to compress it, not a different format. - You have to subscribe to mplayer-dev-eng since we blocked postings from - non-subscribers after spam problems and because patches get reviewed by - the developers on the list. We want you to be available for discussing - your code, you might be asked to make modifications before we accept it. - Don't worry, mplayer-dev-eng is not high traffic and you can subscribe - but unset the "Mail delivery" option so that you can post without getting - any mails. - Do not upload the patch to a web or FTP site, send it directly to the - mailing list. The fewer steps it takes us to get at the patch the higher - the likelihood for it to get reviewed and applied. If your patch is so - big you cannot send it by mail, try splitting it into smaller pieces. - -10. Give us a few days to react. We try to review patches as fast as possible, - but unfortunately we are constantly overloaded with work, be it MPlayer- - related or from our day to day lives. If your patch seems to be ignored, - send a reminder asking for opinions as a reply to the original patch and - mention that you got ignored. We are interested in your work and will - eventually either accept it or reject it with an explanation of what we - disliked about your patch. We will often ask you to make changes to your - patch to make it acceptable. Implement them if you want to see your patch - applied and send the update to the mailing list. Remember that updates and - reminders must be sent as replies to the original patch to preserve proper - mail threading. - -11. Do not immediately ask for Subversion write access. If you have contributed - one or more nice, acceptable patches and they need maintaining or you want - to be an MPlayer developer, you'll get Subversion write access. - -12. For consistency reasons, all option names must use '-' instead of '_'. - -13. If you make a nontrivial contribution and wish to be mentioned in the - AUTHORS file, include that in your patch. - -14. Do not use printf for console output, use our own mp_msg functions instead. - For the output to be translated (which includes all messages of level - MSGL_HINT and below), put the strings in help/help_mp-en.h. If you change - strings, remove the occurrences of these strings from the translations. - There may be (compilation) trouble if outdated translations remain in place - and translators will pick up changes more easily if they see a new message - that has to be translated. - -15. If you send a modified or updated version of your patch, resend the - complete patch. It is very time-consuming and error-prone to piece - together patches that are distributed over several mails. - Please always resend patches as replies to the original mail to keep - the thread with the discussion together. - -Thank you! |