0
0
mirror of https://github.com/mpv-player/mpv.git synced 2024-09-20 12:02:23 +02:00

DOCS/contribute.md: some updates

Some of this is outdated by years. I don't think we even have
MPlayer-style randomly formatted source files anymore (except
stream_dvd.c).
This commit is contained in:
wm4 2017-06-24 21:02:45 +02:00
parent aa458c1fef
commit 21e1bb9807

View File

@ -17,6 +17,14 @@ Sending patches
- All new code must be LGPLv2.1+ licensed, or come with the implicit agreement
that it will be relicensed to LGPLv2.1+ later (see ``Copyright`` in the
repository root directory).
- You must be either the exclusive author of the patch, or acknowledge all
authors involved in the commit message. If you take 3rd party code, authorship
and copyright must be properly acknowledged. If the license of the code is not
LGPLv2.1+, this must be mentioned.
- Don't use fake names (something that looks like an actual names, and may be
someone else's name, but is not your legal name). Using a pseudonyms is
allowed if it can be used to identify or contact you, even if whatever
account you used to submit the patch dies.
- When creating pull requests, be sure to test your changes. If you didn't,
please say so in the pull request message.
- Write informative commit messages. Use present tense to describe the
@ -55,11 +63,14 @@ Sending patches
additional cosmetic changes in the same file you're working on. But don't do
something like reformatting a whole file, and hiding an actual functional
change in the same commit.
- If you add a new command line option, document it in options.rst. If you
add a new input property, document it in input.rst. Changes to the user
interface (options, properties, commands) should be documented in
interface-changes.rst. Changes to libmpv should be documented in
client-api-changes.rst.
- Changes to command line options (addition/modification/removal) must be
documented in options.rst. Changes to input properties or input commands must
be documented in input.rst. All changes to the user interface (options,
properties, commands) must be documented with a small note in
interface-changes.rst (although documenting additions is optional, and
obscure corner cases and potentially be skipped too). Changes to the libmpv
API must be reflected in the libmpv's headers doxygen, and should be
documented in client-api-changes.rst.
Code formatting
---------------
@ -130,11 +141,6 @@ mpv uses C99 with K&R formatting, with some exceptions.
}
```
- Remove any trailing whitespace.
- If the file you're editing uses formatting different from from what is
described here, it's probably an old file from times when nobody followed a
consistent style. You're free to use the existing style, or the new style, or
to send a patch to reformat the file to the new style before making functional
changes.
General coding
--------------
@ -150,7 +156,6 @@ General coding
- Prefer fusing declaration and initialization, rather than putting declarations
on the top of a block. Obvious data flow is more important than avoiding
mixing declarations and statements, which is just a C90 artifact.
- tech-overview.txt might help to get an overview how mpv is structured.
- If you add features that require intrusive changes, discuss them on the dev
channel first. There might be a better way to add a feature and it can avoid
wasted work.