On Sun, Dec 6, 2015 at 8:46 AM, wm4 <nfx...@googlemail.com> wrote:
> 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.
But that is covered in point 1: patches get sent to the ML. This needs
to be done regardless. What a user does on top is really up to them,
e.g referencing a git tree in the patch notes.
>
>> @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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
