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.
OSDN Git Service
