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

[Rostislav Pehlivanov]

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.
>> ---
>> doc/developer.texi | 10 +++++++++-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/doc/developer.texi b/doc/developer.texi
>> index dbe1f5421f..41551498ad 100644
>> --- a/doc/developer.texi
>> +++ b/doc/developer.texi
>> @@ -338,13 +338,21 @@ you applied the patch.
>> When applying patches that have been discussed (at length) on the mailing
>> list, reference the thread in the log message.
>>
>> - at subheading Always wait long enough before pushing changes
>> + at subheading Always wait long enough before pushing changes to code
>> actively maintained by others
>> Do NOT commit to code actively maintained by others without permission.
>> Send a patch to ffmpeg-devel. If no one answers within a reasonable
>> time-frame (12h for build failures and security fixes, 3 days small
>> changes,
>> 1 week for big patches) then commit your patch if you think it is OK.
>> Also note, the maintainer can simply ask for more time to review!
>>
>> + at subheading Pushing patches without sending them to the mailing list
>> +If you're the maintainer of a file, or the file is not actively
>> maintained by
>> +anyone, or the file is not covered by the MAINTAINERS file, you can just
>> push
>> +them without asking for permission, and without sending them to
>> ffmpeg-devel.
>> +This right only applies to developers with git push access, of course.
>> +A maintainer is considered not active if he hasn't posted a mail to
>> ffmpeg-devel
>> +for longer than 6 months, and hasn't pushed a patch in that time period
>> himself.
>> +
>>
>
> Instead of this, I'd prefer all patches on the ML. Exceptions can be OKish
> (e.g. libav merges, which are hard as they are, or very trivial fixes), but
> I definitely would not make unreviewed pushes an encouraged and written
> policy.
>
>
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.


> 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.