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

[Ivan Kalvachev]

On 4/6/14, 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?
> Uhm, competition?
> Foss projects foster on innovative ways of tackling problems, and that
> pushes developers to improve their code. When a project keeps pulling
> features from another and adding on top of it, it stifles competition and
> demotivates developers, with the end result that *less* open source code is
> written.

This doesn't make any sense. We are not talking about the invisible
hand of the free market or the survival of the fittest.

The real power of Free Open Source Software is the cooperation, not
the competition. Why should we discard good and tested code to write
something again and again. How many times a single problem should be
solved until we stop writing new code for solving it?

Not having to repeatedly solve the same problem means that developers
could focus on finding and solving new problems.


I hope you have read the "The Cathedral and the Bazaar". Maybe you
should read it again.

> 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

Code doesn't smell.

(it might suck, but it doesn't smell;) )

>> When a new feature arrives in avconv, what happens if it is not merged into
>> ffmpeg? Shall it be left out? Or re-implemented independently?
>
>
> Being left out until someone actually needs it is a way. Otherwise you just
> get complaints and unnecessary features that might collide with your design
> goals. See for example the mv visualization deprecation and undeprecation
> of a few days ago or many others I could quote.

And how are we supposed to find out that some user might need a feature?
Users are not going to complain, they will use the tool that have that feature.

>> The first one is bad for the users, the second one is a waste of
>> developers'
>> time.
>
>
> This whole downstream situation is bad for users and developers. This is
> why I'm insisting to get past each other differences and see if there is
> room for collaboration, rather than one-way pulling.

You see, talking/thinking about upstream and downstream is the thing
that is causing confusion here.

If you stop thinking in these terms and then imagine libav and ffmpeg
as two separate repositories of a single project, then maybe you will
figure out what is going on.

GIT have been developed specifically to enable distributed
development. This is also how Linux kernel development works and it
might be good idea to watch/read some lectures about it.

The problem is indeed "the one way pulling".
Libav refuses to merge directly from FFmpeg. It takes higher priority
to have nice linear white-washed history. It even prefers to botcher
proper code authorship attribution.
That refusal is not pragmatic and is based solely on political and
personal reasons.


On 4/10/14, Vittorio Giovara <vittorio.giovara at gmail.com> wrote:
> 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.

Because this is the very reason Libav exists - to kick out Michael
Niedermayer and the people who support him.

This is why the takeover from 18.Jan.2011 happened.
This is why he is banned from Libav maillist - a clear statement that
his input is not wanted or needed.
This is why removing his ban is so important.


> Rather than complaining in the ffmpeg-devel mailing list (where no
> Libav dev can listen) for a random change introduced in Libav (and

Libav developers are welcome to FFmpeg lists and so far nobody have been banned.
Lists are open and archives are public. The two irc channels are also
open and public and are been logged for the sake of keeping
development related discussions.


> then merged), it would be wiser to have communication channel directly
> with the source of those changes.
> Or stop merging,

We are forced to keep compatibility with Libav for as long as major
distributions are packaging it as the only replacement for FFmpeg.
There are many project that are forced to be compatible with the Libav
API. If they choose to stick to FFmpeg, they will be dropped by these
distributions. (And yes, that has already happened).

> but I don't think you have that communication link
> with the one who decides what to merge either.

Michael Niedermayer is the the developer who merges Libav into FFmpeg.
He answers on this maillist and on the irc channel.
You have already talked with him.

>> 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.

We trust Michael Niedermayer to sort out the API problems. This is
another reason to remove his ban from Libav maillists.

>> 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.

Let me be blunt.
It's not FFmpeg that have problem with Libav, it is the other way around.

We have no problem reviewing and accepting code from Libav developers.
We merge their code even if we don't like it.

We however don't feel welcome in Libav. And there are a numerous
concrete reasons for that. Some of them have already been given by
others.


On 4/10/14, Vittorio Giovara <vittorio.giovara at gmail.com> wrote:
> On Mon, Apr 7, 2014 at 12:23 AM, Ivan Kalvachev <ikalvachev at gmail.com>
> wrote:
>>>> For now I'll try to be constructive:
>>>
>>> Thanks ^^
>>
>> I said "for now" :E
>
> I don't get this animosity :\

That's not animosity. I'm well aware that at some point the arguments
would balloon exponentially.
That's why I am starting with 2 concrete simple goals and trying to
tie all arguments around them.

>>>> 1. Do you have a commit right to git and could you find a(nother)
>>>> committer who is willing to put higher priority to review and apply
>>>> patches sent from FFmpeg to Libav.
>>>
>>> Only one review is needed, of course that depends on the complexity of
>>> the patch and area of expertise of the reviewer.
>>> I don't think I can guarantee higher priority to anyone as reviews are
>>> carried out in free time and noone is employed in doing so.
>>
>> You didn't answer my question: Do you have commit access?
>
> How would this change anything? Committers cannot send patches if they
> have not been reviewed anyway.

So if I send a patch to libav maillist, you cannot review and push it?
Looks like the 2 developers rule still applies.

Is there another Libav developer besides you, who wants to cooperate
with FFmpeg?
Somebody willing to review/push patches?

>> We are well aware how review process works. In the old FFmpeg the
>> review process was insanely hard with multiple tries/passes. It was
>> quite burdensome for the developers and it was one of the main reasons
>> for people disliking Michael Ni. and wanting a change.
>>
>> After the fork FFmpeg relaxed that model drastically and it does seem
>> to work much better. Just like it does for a numerous different
>> projects.
>
> For ffmpeg developers that might true, I'm not so sure for the project
> consistency and for the benefit of the users.

Well, if you haven't noticed, users prefer FFmpeg because it does have
less bugs and more features.

> FWIW I could name a few foss projects whose review time is much longer
> than Libav's.

And as I have already said, FFmpeg have been a successful project for
a much longer time with much stricter review process.
Been there, done that.

>> Anyway, from your words I see that you are literally not taking any
>> personal responsibility.
>
> I'm not sure why I would have to. Again, I'm not gaining anything from
> Libav, much less from ffmpeg, so I don't quite understand why I would
> have to take a personal responsibility.
> It should be a shared decision from both groups, with clear
> cooperation and respect statements.

However even you alone are not making clear cooperation statement.

When you talk the talk, you have to walk the walk.


>> You are not promising that you are going to review FFmpeg patches and
>> that you will commit reviewed and approved patches.
>>
>> Are you going to at least start nagging your libav peers to review the
>> patches from FFmpeg? Why don't you try to do that with the patches
>> that were pointed above.
>>
>> Do something.
>
> Trying to establish communication links between projects that hate
> each other is already a daunting task...

Ever heard that "actions speak more than thousand words"?

>>>> 2. Can you remove the ban on FFmpeg developers from the libav maillist
>>>> and irc channels?
>>>> Most importantly, Michael's.
>>>
>>> AFAIK there is no ban on anyone, besides Michael. I am not sure why
>>> that's so important to you, but such decision could certainly not be
>>> taken by a person alone.
>>> Of course if the flow of communication, collaboration and respect
>>> between the two projects increased, I believe that there could be room
>>> for bringing this topic up for discussion.
>>
>> There is nothing to discuss. Either Libav removes all bans or there is
>> no point in wasting time with empty talks.
>>
>> First check all emails that Michael have sent to libav* maillists and
>> see for yourself that there have never been any reason to ban him.
>
> It's hard to reply without reminding sad past topics, arousing trolls
> (a few have already took part uninvited) and hijacking this
> conversation.
> So rather than finding the reasons that led to the ban, let's find
> reasons to remove the ban.

Now I'm curious. I definitely want to hear the explanation they told to you.

You see, I know the reasons for the ban. The reason is spite and hate.
This ban standing there means that spite and hate are not gone.
It is sign "You and your kind are now welcome here".

There could be no meaningful respect statement, while the ban is still standing.

>> Then ask your peers for the reason this ban is still standing and
>> request the ban to be removed. And better get their answers in
>> writing. (Because if they refuse, I want to read why.)
>
> Umh I'm not quite sure how to interpret all this.
> I mean, I find it silly that you ask me (2nd person) to ask about
> Michael (3rd person) to a 4th or a 5th person. Isn't it faster to ask
> it yourself?

I already know the reason for the ban and what would happen if I ask about it.
However you are likely not going to believe me, until you try it for yourself.

>> If you want to establish a common ground, then you have to first show
>> at least a sign of good faith.
>
> Given that in this ~30 email conversion I've received more or less 4
> constructive emails I'm already showing a lot of faith continuing it.
> If you agree that it could be interesting to work together, I need to
> have something to work on, that show some real intentions of
> cooperation; having a "do this or stfu" can't really lead anywhere.
> Much less the troll attempts in the other emails that got duly
> ignored.

I still don't get it. What exactly do you want from FFmpeg in order to
"show some real intentions of cooperation"?

IMHO, the fact that we merge Libav code does mean that we cooperate
with them, even if Libav doesn't want to. But that's the price to pay
for working with foss code base.

Do you want us to stop merging Libav? This would literally cut our
ties and any reason for cooperation.
Do you want us to tell you about Libav bugs? How about remove the ban
of the person who does most of Libav merges and finds these bugs
first?
Do you want us to send patches to Libav maillist? How about start
reviewing the patches that have already been sent?


I do not believe that there are enough people in Libav that want Libav
to cooperate with FFmpeg.

I'd like to be proven wrong. Let Michael send patches directly and
find another Libav developer willing to help with reviewing and
pushing FFmpeg patches.