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

[Hendrik Leppkes]

On Sat, Feb 25, 2017 at 11:47 PM, Rostislav Pehlivanov
<atomnuker at gmail.com> wrote:
>>
>> 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.
>>
>>
> Review or not, too slow still. If I have a fix for something I wrote and
> understand I'm not willing to wait and I'll push it, if I have some doubts
> I'll post it to the ML. You seem to give people way less trust than they
> deserve, especially if they have commit rights. I can't accept that.

I would say that if you are the maintainer of something, you should be
able to push to it, but still be encouraged to post to the ML with
bigger changes (not simple fixes), but things that are unmaintained or
maintained by someone else should generally go through the ML.
Thats how most had interpreted the policy in the past, I would think,
even if it didn't agree with the written policy entirely.

- Hendrik