[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