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. -@subheading Always wait long enough before pushing changes +@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! +@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 -- 2.11.0 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
