har0ke/FFmpeg
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

doc/developer: remove duplicate policies and fix error

Browse Source 
Fixes regression as of ee72b6d1

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Josh de Kock <josh@itanimul.li>
Signed-off-by: James Almer <jamrial@gmail.com>
This commit is contained in:
Josh de Kock 2016-10-04 23:10:00 +01:00 committed by James Almer
parent b33369b612
commit 5173ffb27f
1 changed files with 2 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
doc/developer.texi
View File

@ -293,12 +293,7 @@ later on.
Also if you have doubts about splitting or not splitting, do not hesitate to Also if you have doubts about splitting or not splitting, do not hesitate to
ask/discuss it on the developer mailing list. ask/discuss it on the developer mailing list.
@item API/ABI changes should be discussed before they are made. @subheading Ask before you change the build system (configure, etc).
Do not change behavior of the programs (renaming options etc) or public
API or ABI without first discussing it on the ffmpeg-devel mailing list.
Do not remove widely used functionality or features (redundant code can be removed).
@item Ask before you change the build system (configure, etc).
Do not commit changes to the build system (Makefiles, configure script) Do not commit changes to the build system (Makefiles, configure script)
which change behavior, defaults etc, without asking first. The same which change behavior, defaults etc, without asking first. The same
applies to compiler warning fixes, trivial looking fixes and to code applies to compiler warning fixes, trivial looking fixes and to code
@ -307,7 +302,7 @@ the way we do. Send your changes as patches to the ffmpeg-devel mailing
list, and if the code maintainers say OK, you may commit. This does not list, and if the code maintainers say OK, you may commit. This does not
apply to files you wrote and/or maintain. apply to files you wrote and/or maintain.
@item Cosmetic changes should be kept in separate patches. @subheading Cosmetic changes should be kept in separate patches.
We refuse source indentation and other cosmetic changes if they are mixed We refuse source indentation and other cosmetic changes if they are mixed
with functional changes, such commits will be rejected and removed. Every with functional changes, such commits will be rejected and removed. Every
developer has his own indentation style, you should not change it. Of course developer has his own indentation style, you should not change it. Of course
@ -356,15 +351,6 @@ Do not change behavior of the programs (renaming options etc) or public
API or ABI without first discussing it on the ffmpeg-devel mailing list. API or ABI without first discussing it on the ffmpeg-devel mailing list.
Do not remove widely used functionality or features (redundant code can be removed). Do not remove widely used functionality or features (redundant code can be removed).
@subheading Ask before you change the build system (configure, etc).
Do not commit changes to the build system (Makefiles, configure script)
which change behavior, 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-devel mailing
list, and if the code maintainers say OK, you may commit. This does not
apply to files you wrote and/or maintain.
@subheading Remember to check if you need to bump versions for libav*. @subheading Remember to check if you need to bump versions for libav*.
Depending on the change, you may need to change the version integer. Depending on the change, you may need to change the version integer.
Incrementing the first component means no backward compatibility to Incrementing the first component means no backward compatibility to