[FFmpeg-devel] [PATCH] doc: clarify development rules
atomnuker at gmail.com
Sat Feb 25 19:59:10 EET 2017
On 25 February 2017 at 14:59, wm4 <nfxjfg at googlemail.com> 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
> 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
> +them without asking for permission, and without sending them to
> +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
> +for longer than 6 months, and hasn't pushed a patch in that time period
> @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
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel