Revision 7a57b90c doc/ffmpeg-doc.texi

View differences:

doc/ffmpeg-doc.texi
1048 1048
fprintf and printf are forbidden in libavformat and libavcodec, 
1049 1049
please use av_log() instead.
1050 1050

  
1051
@node CVS Policy
1052
@section CVS Policy
1053

  
1054
@enumerate
1055
@item 
1056
   You must not commit code which breaks FFmpeg! (Meaning unfinished but
1057
   enabled code which breaks compilation or compiles but does not work. Or 
1058
   breaks the regression tests)
1059
   You can commit unfinished stuff (for testing etc), but it must be disabled
1060
   (#ifdef etc) by default so it does not interfere with other developers'
1061
   work.
1062
@item 
1063
   You don't have to over-test things. If it works for you, and you think it
1064
   should work for others, too, then commit. If your code has problems
1065
   (portability, exploits compiler bugs, unusual environment etc) they will be
1066
   reported and eventually fixed.
1067
@item 
1068
   Do not commit unrelated changes together, split them into self-contained
1069
   pieces.
1070
@item
1071
   Do not change behavior of the program (renaming options etc) without
1072
   first discussing it on the ffmpeg-dev mailing list. Do not remove
1073
   functionality from the code. Just improve!
1074
   
1075
   Note: Redundant code can be removed
1076
@item
1077
   Do not commit changes to the build system (Makefiles, configure script)
1078
   which change behaviour, defaults etc, without asking first. The same
1079
   applies to compiler warning fixes, trivial looking fixes and to code
1080
   maintained by other developers. We usually have a reason for doing things
1081
   the way we do. Send your changes as patches to the ffmpeg-dev mailing
1082
   list, and if the code maintainers say OK, you may commit. This does not
1083
   apply to files you wrote and/or maintain.
1084
@item
1085
   We refuse source indentation and other cosmetic changes if they are mixed
1086
   with functional changes, such commits will be rejected and removed. Every
1087
   developer has his own indentation style, you should not change it. Of course
1088
   if you (re)write something, you can use your own style, even though we would
1089
   prefer if the indention throughout ffmpeg would be consistant (Many projects
1090
   force a given indentation style - we don't.) If you really need to make
1091
   indentation changes (try to avoid this), separate them strictly from real
1092
   changes.
1093

  
1094
   NOTE: If you had to put if(){ .. } over a large (> 5 lines) chunk of code,
1095
   then either do NOT change the indentation of the inner part within (don't 
1096
   move it to the right)! or do so in a seperate commit
1097
@item
1098
   Always fill out the commit log message. Describe in a few lines what you
1099
   changed and why. You can refer to mailing list postings if you fix a
1100
   particular bug. Comments such as "fixed!" or "Changed it." are unacceptable.
1101
@item
1102
   If you apply a patch by someone else, include the name and email address in
1103
   the CVS log message. Since the ffmpeg-cvslog mailing list is publicly
1104
   archived you should add some spam protection to the email address. Send an
1105
   answer to ffmpeg-dev (or wherever you got the patch from) saying that
1106
   you applied the patch.
1107
@item
1108
   Do NOT commit to code actively maintained by others without permission. Send
1109
   a patch to ffmpeg-dev instead.
1110
@item
1111
    Subscribe to the ffmpeg-cvslog mailing list. The diffs of all CVS commits
1112
    are sent there and reviewed by all the other developers. Bugs and possible
1113
    improvements or general questions regarding commits are discussed there. We
1114
    expect you to react if problems with your code are uncovered.
1115
@item
1116
    Update the documentation if you change behavior or add features. If you are
1117
    unsure how best to do this, send a patch to ffmpeg-dev, the documentation
1118
    maintainer(s) will review and commit your stuff.
1119
@item
1120
    Revert a commit ONLY in case of a big blunder like committing something not
1121
    intended to be committed or committing a wrong file, the wrong version of a
1122
    patch, cvs policy violation or broken code and you are going to recommit the
1123
    right thing immediately.
1124

  
1125
    Never revert changes made a long time ago or buggy code. Fix it in the
1126
    normal way instead.
1127
@end itemize
1128

  
1129
We think our rules are not too hard. If you have comments, contact us.
1130

  
1131
Note, these rules are mostly borrowed from the MPlayer project.
1132

  
1133
@subsection Renaming/moving files or content of files
1134
  You CANNOT do that. Post a request for such a change to the mailinglist
1135
  Do NOT remove & readd a file - it will kill the changelog!!!!
1136

  
1051 1137
@section Submitting patches
1052 1138

  
1053 1139
First, (@pxref{Coding Rules}) above if you didn't yet.

Also available in: Unified diff