[FFmpeg-devel] [PATCH] doc: clarify development rules

Marton Balint cus at passwd.hu
Sat Feb 25 22:23:27 EET 2017

On Sat, 25 Feb 2017, Rostislav Pehlivanov wrote:

> On 25 February 2017 at 18:35, Marton Balint <cus at passwd.hu> wrote:
>> On Sat, 25 Feb 2017, wm4 wrote:
>> I'm documenting existing practice.
>>> I'm pulling the "6 months" timeout out of my ass, but I think it's
>>> pretty suitable.
>>> ---


> This is the way it has been done for years and its the way the project has
> been able to move as rapidly as it has. That would slow down anything large
> from being developed in the codebase, like encoders or decoders for a new
> format, which are usually being developed by a single person who
> understands the code better than anybody. I am okay with it being an
> unwritten rule, anyone who needs to know about it knows about it and
> everyone that knows about it knows that moderation is the key. But
> forbidding it will kill the project.

I only want to have a chance to review before patches got pushed. I am not 
saying we should explicitly demand a review for each patch. So this 
normally should only cause any developer an additional sent email to the 
ML and 1-2 days of delay. With git, I don't think this is that much 
additional work.

Of course, I could just subscribe to csvlog as well, and give post-commit 
reviews if I want, it is just better to do it earlier, and less chance of 
revert wars, because with the 'written' rule above I just as easily revert 
anything in unmaintained code without a discussion, and remain within the 

>> If this gets pushed, I am inclined to clean up the MAINTAINERS file and
>> remove everybody who is no longer "active", and assume maintainership of
>> parts I actively use and care about, but which has no maintainership
>> anymore.
> So you're okay as long as maintainers gets sorted out? You might as well do
> it, its what's the file is supposed to reflect.

I still prefer if this is not applied. MAINTAINERS file might be cleaned 
up regardless of this patch, however I think we should at least ping 
everybody we are trying to remove from it.


More information about the ffmpeg-devel mailing list