mirror of
https://github.com/mpv-player/mpv
synced 2024-12-24 07:42:17 +00:00
11e03076eb
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@21488 b3059339-0415-0410-9bf9-f77b7e298cf2
118 lines
6.4 KiB
Plaintext
118 lines
6.4 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 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!
|
|
|
|
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 a base64-encoded
|
|
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!
|