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

[Ivan Kalvachev]

On 2/25/17, wm4 <nfxjfg at googlemail.com> 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.
> +
>  @subsection Code
>  @subheading API/ABI changes should be discussed before they are made.
>  Do not change behavior of the programs (renaming options etc) or public

I object on this.

I do prefer all the code to go though the maillist.
Even trivial changes.