cvs policy

Originally committed as revision 3701 to svn://svn.ffmpeg.org/ffmpeg/trunk

1 files changed, 86 insertions, 0 deletions

diff --git a/doc/ffmpeg-doc.texi b/doc/ffmpeg-doc.texi
index e0caed02f5..0a96ac4c50 100644
--- a/doc/ffmpeg-doc.texi
+++ b/doc/ffmpeg-doc.texi
@@ -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.