[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
'rules'.
>> 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.
Regards,
Marton
More information about the ffmpeg-devel
mailing list