[FFmpeg-devel] [RFC] Reviewing merges

[James Almer]

On 5/1/2017 3:13 PM, Marton Balint wrote:
> 
> On Mon, 24 Apr 2017, wm4 wrote:
> 
>> On Mon, 24 Apr 2017 21:14:15 +0200 (CEST)
>> Marton Balint <cus at passwd.hu> wrote:
>>
>>> On Mon, 24 Apr 2017, Michael Niedermayer wrote:
>>> > On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:
>>> >> We have recently been able to go through six hundred or so commits
>>> in a
>>> >> month or two this way after being stuck for the longest time by a
>>> few of
>>> >> those big API changes. If we start requiring every commit to go
>>> through
>>> >> a review process on the ML then we will never catch up with the
>>> backlog.
>>> >> In short, things as they are right now are smooth. Changing it
>>> will only
>>> >> make this slower. >
>>> > Maybe, but is merging more faster also better for FFmpeg ?
>>> > I did not analyze the bugs on our bug tracker but subjectivly the
>>> > number of regressions seems much larger than a year or 2 ago.
>>> > and i just yesterday found 2 issues in a merge (which you fixed)
>>> >
>>> Yeah, I also have two I recently came across, both caused by the
>>> delayed filter initialization patch:
>>>
>>> https://trac.ffmpeg.org/ticket/6323
>>> https://trac.ffmpeg.org/ticket/6318
>>>
>>> Maybe someone more familiar with ffmpeg.c code can take a look?
>>
>> Currently I'm overworked, I can take a look later if you remind me.
> 
> This is a friendly reminder :)
> 
> Thanks,
> Marton

Similarly, ticket 6227 describes a big regression introduced by this
commit that i'm surprised is not reflected by any FATE test seeing that
a simple "ffmpeg -i INPUT -c:v copy -c:a ENCODER OUTPUT", a very common
use case, is enough to reproduce it.