[FFmpeg-devel] [PATCH] doc: clarify development rules
cus at passwd.hu
Sat Feb 25 20:35:42 EET 2017
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
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
More information about the ffmpeg-devel