diff mbox

[FFmpeg-devel] doc/developer: remove duplicate policies and fix error

Message ID 20161004221000.46147-1-josh@itanimul.li
State Accepted
Commit 5173ffb27f6e3ad25c1b947cda2fb9e196a7918a
Headers show

Commit Message

Josh Dekker Oct. 4, 2016, 10:10 p.m. UTC 
Fixes regression as of ee72b6d1

Signed-off-by: Josh de Kock <josh@itanimul.li>
---
The irony of this patch is terrible, but oh well. Maybe we're missing a
'everyone makes mistakes' policy.

 doc/developer.texi | 18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

Comments

Michael Niedermayer Oct. 4, 2016, 10:20 p.m. UTC | #1 
On Tue, Oct 04, 2016 at 11:10:00PM +0100, Josh de Kock wrote:
> Fixes regression as of ee72b6d1
> 
> Signed-off-by: Josh de Kock <josh@itanimul.li>
> ---
> The irony of this patch is terrible, but oh well. Maybe we're missing a
> 'everyone makes mistakes' policy.
> 
>  doc/developer.texi | 18 ++----------------
>  1 file changed, 2 insertions(+), 16 deletions(-)

should be ok, this is removing duplicate entries


[...]
James Almer Oct. 5, 2016, 1:59 a.m. UTC | #2 
On 10/4/2016 7:20 PM, Michael Niedermayer wrote:
> On Tue, Oct 04, 2016 at 11:10:00PM +0100, Josh de Kock wrote:
>> Fixes regression as of ee72b6d1
>>
>> Signed-off-by: Josh de Kock <josh@itanimul.li>
>> ---
>> The irony of this patch is terrible, but oh well. Maybe we're missing a
>> 'everyone makes mistakes' policy.
>>
>>  doc/developer.texi | 18 ++----------------
>>  1 file changed, 2 insertions(+), 16 deletions(-)
> 
> should be ok, this is removing duplicate entries

Pushed as it broke fate and things were becoming very red very fast.
diff mbox

Patch

diff --git a/doc/developer.texi b/doc/developer.texi
index 3fcfe86..cf809b9 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -293,12 +293,7 @@  later on.
 Also if you have doubts about splitting or not splitting, do not hesitate to
 ask/discuss it on the developer mailing list.
 
-@item API/ABI changes should be discussed before they are made.
-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).
+@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
@@ -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
 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
 with functional changes, such commits will be rejected and removed. Every
 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.
 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*.
 Depending on the change, you may need to change the version integer.
 Incrementing the first component means no backward compatibility to