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

[Marton Balint]

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.

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.

Regards,
Marton