mirror of https://github.com/mpv-player/mpv
69 lines
3.5 KiB
Plaintext
69 lines
3.5 KiB
Plaintext
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.
|
|
|
|
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 the CVS version. The README describes how to check
|
|
out CVS and daily CVS snapshots are available from our download page.
|
|
We do not accept patches for releases or outdated CVS versions.
|
|
|
|
2. Make unified diffs ('diff -Naur' or 'cvs diff -u'). Unified diffs can easily
|
|
be applied with 'patch'. This is much harder with other diff types.
|
|
|
|
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. 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 translations as well.
|
|
|
|
7. Send your patch to the mplayer-dev-eng mailing list as a base64-encoded
|
|
attachment (use gzip or bzip2 *only* if it's bigger than 80k or if you know
|
|
that your mailer messes up (reformats) text attachments) with the subject
|
|
line: '[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.
|
|
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 with the
|
|
nomail option if you do not wish to receive all the mails.
|
|
|
|
8. 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,
|
|
please resend it and mention that you got ignored. We are interested in your
|
|
work and will eventually either accept it or reject it with an explanation
|
|
what and why we disliked about your patch.
|
|
|
|
9. Do not immediately ask for CVS write access. If you contributed one or more
|
|
nice, acceptable patches and they need maintaining or you want to be an
|
|
MPlayer developer, you'll get CVS write access.
|
|
|
|
10. For consistency reasons all option names must use '-' instead of '_'.
|
|
|
|
11. If you made a nontrivial contribution and wish to be mentioned in the
|
|
AUTHORS file, include that in your patch.
|
|
|
|
Thank you!
|