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

wm4 nfxjfg at googlemail.com
Sat Feb 25 16:59:49 EET 2017


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



More information about the ffmpeg-devel mailing list