1
0
mirror of https://github.com/mpv-player/mpv synced 2024-12-14 19:05:33 +00:00
mpv/DOCS/tech/patches.txt
diego f89c93719c Explain why putting [PATCH] in the subject is important.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@7154 b3059339-0415-0410-9bf9-f77b7e298cf2
2002-08-30 00:53:11 +00:00

39 lines
1.6 KiB
Plaintext

Sending patches:
~~~~~~~~~~~~~~~~
Note: We know these rules are hard, but it's hard to maintain such a
big and complex project, so you should accept our rules. We have no
time for fixing buggy, broken or old patches!
1. Always make patches for the CVS version.
We do not accept patches for old versions or releases.
2. Make unified diffs ('diff -Naur' or 'cvs diff -u').
3. Test the functionality of your patch. We'll *refuse* it if it breaks
something, even if it extends other features!
4. Read your patch. We'll *refuse* it if it changes indentation of the
code or if it does tab/space conversion or other cosmetical changes!
5. Comment parts that really need it (tricky side-effects etc).
Commenting trivial code not required. Comments must be English!
6. Do not ask for CVS write access at first time. If you contributed
1 or more nice, acceptable patches and they need maintaining or
you want to be an mplayer developer, you'll get CVS write access.
7. Subscribe to the mplayer-dev-eng list (don't worry, it's low traffic)
and send your patch there as base64-encoded attachment (use gzip or
bzip2 *only* if it's really big or if you know that your mailer messes
up (reformats) text attachments).
Subject line should be: '[PATCH] very short description of the patch'.
In the mail, describe in a few sentences what you change and why.
If you made independent changes, try to send them as separate patches.
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.
Thank you!
A'rpi