summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2017-06-24 21:02:45 +0200
committerwm4 <wm4@nowhere>2017-06-24 21:02:45 +0200
commit21e1bb9807e924a1063ad9161159b6ece8458b87 (patch)
treebccc3f0d51e3f42b2cf523ca1db9316979dd17e7
parentaa458c1fef354d8b5810e8d5acbd0bdb0952f51c (diff)
downloadmpv-21e1bb9807e924a1063ad9161159b6ece8458b87.tar.bz2
mpv-21e1bb9807e924a1063ad9161159b6ece8458b87.tar.xz
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).
-rw-r--r--DOCS/contribute.md27
1 files changed, 16 insertions, 11 deletions
diff --git a/DOCS/contribute.md b/DOCS/contribute.md
index c7226ec819..67979c31b8 100644
--- a/DOCS/contribute.md
+++ b/DOCS/contribute.md
@@ -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.