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. -@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. +
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 written policy.
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 anymore.
Regards, Marton _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
