From 7a57b90c335c4c3e64ba6cdacfb9869773adb8b0 Mon Sep 17 00:00:00 2001 From: Michael Niedermayer Date: Sun, 21 Nov 2004 14:30:50 +0000 Subject: [PATCH] cvs policy Originally committed as revision 3701 to svn://svn.ffmpeg.org/ffmpeg/trunk --- doc/ffmpeg-doc.texi | 86 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 86 insertions(+) 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.