From 21e1bb9807e924a1063ad9161159b6ece8458b87 Mon Sep 17 00:00:00 2001 From: wm4 Date: Sat, 24 Jun 2017 21:02:45 +0200 Subject: [PATCH] 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). --- DOCS/contribute.md | 27 ++++++++++++++++----------- 1 file 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.