- Contributions should be licensed under the LGPL 2.1, including an
- "or any later version" clause, or the MIT license. GPL 2 including
- an "or any later version" clause is also acceptable, but LGPL is
- preferred.
-@item
- You must not commit code which breaks FFmpeg! (Meaning unfinished but
- enabled code which breaks compilation or compiles but does not work or
- breaks the regression tests)
- You can commit unfinished stuff (for testing etc), but it must be disabled
- (#ifdef etc) by default so it does not interfere with other developers'
- work.
-@item
- You do not have to over-test things. If it works for you, and you think it
- should work for others, then commit. If your code has problems
- (portability, triggers compiler bugs, unusual environment etc) they will be
- reported and eventually fixed.
-@item
- Do not commit unrelated changes together, split them into self-contained
- pieces. Also do not forget that if part B depends on part A, but A does not
- depend on B, then A can and should be committed first and separate from B.
- Keeping changes well split into self-contained parts makes reviewing and
- understanding them on the commit log mailing list easier. This also helps
- in case of debugging later on.
- Also if you have doubts about splitting or not splitting, do not hesitate to
- ask/discuss it on the developer mailing list.
-@item
- Do not change behavior of the programs (renaming options etc) or public
- API or ABI without first discussing it on the ffmpeg-devel mailing list.
- Do not remove functionality from the code. Just improve!
-
- Note: Redundant code can be removed.
-@item
- Do not commit changes to the build system (Makefiles, configure script)
- which change behavior, defaults etc, without asking first. The same
- applies to compiler warning fixes, trivial looking fixes and to code
- maintained by other developers. We usually have a reason for doing things
- the way we do. Send your changes as patches to the ffmpeg-devel mailing
- list, and if the code maintainers say OK, you may commit. This does not
- apply to files you wrote and/or maintain.
-@item
- We refuse source indentation and other cosmetic changes if they are mixed
- with functional changes, such commits will be rejected and removed. Every
- developer has his own indentation style, you should not change it. Of course
- if you (re)write something, you can use your own style, even though we would
- prefer if the indentation throughout FFmpeg was consistent (Many projects
- force a given indentation style - we do not.). If you really need to make
- indentation changes (try to avoid this), separate them strictly from real
- changes.
-
- NOTE: If you had to put if()@{ .. @} over a large (> 5 lines) chunk of code,
- then either do NOT change the indentation of the inner part within (do not
- move it to the right)! or do so in a separate commit
-@item
- Always fill out the commit log message. Describe in a few lines what you
- changed and why. You can refer to mailing list postings if you fix a
- particular bug. Comments such as "fixed!" or "Changed it." are unacceptable.
-@item
- If you apply a patch by someone else, include the name and email address in
- the log message. Since the ffmpeg-cvslog mailing list is publicly
- archived you should add some SPAM protection to the email address. Send an
- answer to ffmpeg-devel (or wherever you got the patch from) saying that
- you applied the patch.
-@item
- When applying patches that have been discussed (at length) on the mailing
- list, reference the thread in the log message.
-@item
- Do NOT commit to code actively maintained by others without permission.
- Send a patch to ffmpeg-devel instead. If no one answers within a reasonable
- timeframe (12h for build failures and security fixes, 3 days small changes,
- 1 week for big patches) then commit your patch if you think it is OK.
- Also note, the maintainer can simply ask for more time to review!
-@item
- Subscribe to the ffmpeg-cvslog mailing list. The diffs of all commits
- are sent there and reviewed by all the other developers. Bugs and possible
- improvements or general questions regarding commits are discussed there. We
- expect you to react if problems with your code are uncovered.
-@item
- Update the documentation if you change behavior or add features. If you are
- unsure how best to do this, send a patch to ffmpeg-devel, the documentation
- maintainer(s) will review and commit your stuff.
-@item
- Try to keep important discussions and requests (also) on the public
- developer mailing list, so that all developers can benefit from them.
-@item
- Never write to unallocated memory, never write over the end of arrays,
- always check values read from some untrusted source before using them
- as array index or other risky things.
-@item
- Remember to check if you need to bump versions for the specific libav
- parts (libavutil, libavcodec, libavformat) you are changing. You need
- to change the version integer.
- Incrementing the first component means no backward compatibility to
- previous versions (e.g. removal of a function from the public API).
- Incrementing the second component means backward compatible change
- (e.g. addition of a function to the public API or extension of an
- existing data structure).
- Incrementing the third component means a noteworthy binary compatible
- change (e.g. encoder bug fix that matters for the decoder).
-@item
- Compiler warnings indicate potential bugs or code with bad style. If a type of
- warning always points to correct and clean code, that warning should
- be disabled, not the code changed.
- Thus the remaining warnings can either be bugs or correct code.
- If it is a bug, the bug has to be fixed. If it is not, the code should
- be changed to not generate a warning unless that causes a slowdown
- or obfuscates the code.
-@item
- If you add a new file, give it a proper license header. Do not copy and
- paste it from a random place, use an existing file as template.
+Contributions should be licensed under the
+@uref{http://www.gnu.org/licenses/lgpl-2.1.html, LGPL 2.1},
+including an "or any later version" clause, or, if you prefer
+a gift-style license, the
+@uref{http://opensource.org/licenses/isc-license.txt, ISC} or
+@uref{http://mit-license.org/, MIT} license.
+@uref{http://www.gnu.org/licenses/gpl-2.0.html, GPL 2} including
+an "or any later version" clause is also acceptable, but LGPL is
+preferred.
+
+@item
+All the patches MUST be reviewed in the mailing list before they are
+committed.
+
+@item
+The Libav coding style should remain consistent. Changes to
+conform will be suggested during the review or implemented on commit.
+
+@item
+Patches should be generated using @code{git format-patch} or directly sent
+using @code{git send-email}.
+Please make sure you give the proper credit by setting the correct author
+in the commit.
+
+@item
+The commit message should have a short first line in the form of
+a @samp{topic: short description} as a header, separated by a newline
+from the body consisting of an explanation of why the change is necessary.
+If the commit fixes a known bug on the bug tracker, the commit message
+should include its bug ID. Referring to the issue on the bug tracker does
+not exempt you from writing an excerpt of the bug in the commit message.
+If the patch is a bug fix which should be backported to stable releases,
+i.e. a non-API/ABI-breaking bug fix, add @code{CC: libav-stable@@libav.org}
+to the bottom of your commit message, and make sure to CC your patch to
+this address, too. Some git setups will do this automatically.
+
+@item
+Work in progress patches should be sent to the mailing list with the [WIP]
+or the [RFC] tag.
+
+@item
+Branches in public personal repos are advised as way to
+work on issues collaboratively.
+
+@item
+You do not have to over-test things. If it works for you and you think it
+should work for others, send it to the mailing list for review.
+If you have doubt about portability please state it in the submission so
+people with specific hardware could test it.
+
+@item
+Do not commit unrelated changes together, split them into self-contained
+pieces. Also do not forget that if part B depends on part A, but A does not
+depend on B, then A can and should be committed first and separate from B.
+Keeping changes well split into self-contained parts makes reviewing and
+understanding them on the commit log mailing list easier. This also helps
+in case of debugging later on.
+
+@item
+Patches that change behavior of the programs (renaming options etc) or
+public API or ABI should be discussed in depth and possible few days should
+pass between discussion and commit.
+Changes to the build system (Makefiles, configure script) which alter
+the expected behavior should be considered in the same regard.
+
+@item
+When applying patches that have been discussed (at length) on the mailing
+list, reference the thread in the log message.
+
+@item
+Subscribe to the
+@uref{https://lists.libav.org/mailman/listinfo/libav-devel, libav-devel} and
+@uref{https://lists.libav.org/mailman/listinfo/libav-commits, libav-commits}
+mailing lists.
+Bugs and possible improvements or general questions regarding commits
+are discussed on libav-devel. We expect you to react if problems with
+your code are uncovered.
+
+@item
+Update the documentation if you change behavior or add features. If you are
+unsure how best to do this, send an [RFC] patch to libav-devel.
+
+@item
+All discussions and decisions should be reported on the public developer
+mailing list, so that there is a reference to them.
+Other media (e.g. IRC) should be used for coordination and immediate
+collaboration.
+
+@item
+Never write to unallocated memory, never write over the end of arrays,
+always check values read from some untrusted source before using them
+as array index or other risky things. Always use valgrind to double-check.
+
+@item
+Remember to check if you need to bump versions for the specific libav
+parts (libavutil, libavcodec, libavformat) you are changing. You need
+to change the version integer.
+Incrementing the first component means no backward compatibility to
+previous versions (e.g. removal of a function from the public API).
+Incrementing the second component means backward compatible change
+(e.g. addition of a function to the public API or extension of an
+existing data structure).
+Incrementing the third component means a noteworthy binary compatible
+change (e.g. encoder bug fix that matters for the decoder).
+
+@item
+Compiler warnings indicate potential bugs or code with bad style.
+If it is a bug, the bug has to be fixed. If it is not, the code should
+be changed to not generate a warning unless that causes a slowdown
+or obfuscates the code.
+If a type of warning leads to too many false positives, that warning
+should be disabled, not the code changed.
+
+@item
+If you add a new file, give it a proper license header. Do not copy and
+paste it from a random place, use an existing file as template.