[FFmpeg-devel] To be or not to be working with libav (was: [PATCHv3] On2 VP7 decoder)

[Vittorio Giovara]

On Mon, Apr 7, 2014 at 1:19 PM, wm4 <nfxjfg at googlemail.com> wrote:
> On Sun, 6 Apr 2014 20:41:03 +0200
> Vittorio Giovara <vittorio.giovara at gmail.com> wrote:
>
>> On Sunday, April 6, 2014, Nicolas George <george at nsup.org> wrote:
>>
>> > Le septidi 17 germinal, an CCXXII, Vittorio Giovara a écrit :
>> > > The easiest solution would be to stop the daily merge and let the two
>> > > projects live on their own
>> >
>> > You keep suggesting that: what good do you think that would achieve?
>>
>> Also Libav code is so ill received most of the times that I seriously can't
>> figure out why this is still happening. The two projects have completely
>> separate design approach and dev model so it's really difficult to
>> understand, in my opinion
>
> I don't always understand it either. But in general, full merges are
> seen as necessary evil within FFmpeg. The loss of control probably
> contributes to the fact that Libav changes are seen much more
> critically as opposed to if they had been discussed and reviewed by
> FFmpeg developers too.

FFmpeg devs are welcome to join libav-devel and check the patches,
propose changes and notify bugs. I'm not sure what caused so many
people to think that Libav won't listen to (serious) development
problems and modify patches accordingly.
Rather than complaining in the ffmpeg-devel mailing list (where no
Libav dev can listen) for a random change introduced in Libav (and
then merged), it would be wiser to have communication channel directly
with the source of those changes.
Or stop merging, but I don't think you have that communication link
with the one who decides what to merge either.

> What are you suggesting? What kind of collaboration? By the way, it
> would be much easier if Libav merged everything FFmpeg does (and
> routinely does so), because if the code is the same, there is no
> problem in the first place.

For the benefit of the users, I would suggest to *at least* keep the
API offer synchronized, like I explained in my previous email.

> I envision the following "double filtering" development process:
>
>    FFmpeg -> cherrypick by Libav dev -> Libav -> merge -> FFmpeg -> repeat
>
> This way the code will be incrementally improved by funneling a patch
> through review and merge processes a few times.

In a normal world one could envision ffmpeg and libav as two branches,
one for the development/hacks/quickbugfix and the other for stable
development. To this goal both project should share development effort
and accept compromises in design goals. Given the difficulties of
communication between the projects (and unjustified hate perpetuated
by some people) don't see this happening, unfortunately.

-- 
Vittorio