mirror of https://github.com/mpv-player/mpv
82 lines
4.2 KiB
Plaintext
82 lines
4.2 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. 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 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 be
|
|
applied easily 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!
|
|
|
|
NOTE: If you alread 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!
|
|
|
|
5. 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!
|
|
|
|
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 some of the
|
|
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.
|
|
|
|
12. Do not compress your patch unless it is very large. It only makes handling
|
|
the patch more difficult.
|
|
|
|
Thank you!
|