On Sat, 5 Dec 2015 21:49:55 -0800
Timothy Gu <timothyg...@gmail.com> wrote:
> The _de facto_ policy on patch submission has always been "sending it to
> the mailing list."
> ---
> doc/developer.texi | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 9a901d8..9383b21 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -32,13 +32,11 @@ consult @url{https://ffmpeg.org/legal.html}.
>
> @section Contributing
>
> -There are 3 ways by which code gets into ffmpeg.
> +There are two ways by which code gets into ffmpeg.
> @itemize @bullet
> @item Submitting Patches to the main developer mailing list
> see @ref{Submitting patches} for details.
> @item Directly committing changes to the main tree.
> -@item Committing changes to a git clone, for example on github.com or
> - gitorious.org. And asking us to merge these changes.
Technically, doing this is ok. We just don't want to use github's pull
request UI. Changes should be reviewed and discussed on the ML. But
posting on the ML and linking to an existing git tree isn't too bad, I
suppose.
> @end itemize
>
> Whichever way, changes should be reviewed by the maintainer of the code
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
