Commit 7a57b90c authored by Michael Niedermayer's avatar Michael Niedermayer

cvs policy

Originally committed as revision 3701 to svn://svn.ffmpeg.org/ffmpeg/trunk
parent cbb6e405
......@@ -1048,6 +1048,92 @@ int myfunc(int my_parameter)
fprintf and printf are forbidden in libavformat and libavcodec,
please use av_log() instead.
@node CVS Policy
@section CVS Policy
@enumerate
@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 don't have to over-test things. If it works for you, and you think it
should work for others, too, then commit. If your code has problems
(portability, exploits 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.
@item
Do not change behavior of the program (renaming options etc) without
first discussing it on the ffmpeg-dev 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 behaviour, 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-dev 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 indention throughout ffmpeg would be consistant (Many projects
force a given indentation style - we don't.) 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 (don't
move it to the right)! or do so in a seperate 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 CVS 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-dev (or wherever you got the patch from) saying that
you applied the patch.
@item
Do NOT commit to code actively maintained by others without permission. Send
a patch to ffmpeg-dev instead.
@item
Subscribe to the ffmpeg-cvslog mailing list. The diffs of all CVS 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-dev, the documentation
maintainer(s) will review and commit your stuff.
@item
Revert a commit ONLY in case of a big blunder like committing something not
intended to be committed or committing a wrong file, the wrong version of a
patch, cvs policy violation or broken code and you are going to recommit the
right thing immediately.
Never revert changes made a long time ago or buggy code. Fix it in the
normal way instead.
@end itemize
We think our rules are not too hard. If you have comments, contact us.
Note, these rules are mostly borrowed from the MPlayer project.
@subsection Renaming/moving files or content of files
You CANNOT do that. Post a request for such a change to the mailinglist
Do NOT remove & readd a file - it will kill the changelog!!!!
@section Submitting patches
First, (@pxref{Coding Rules}) above if you didn't yet.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment