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

Ivan Kalvachev ikalvachev at gmail.com
Thu Apr 17 21:39:00 CEST 2014


On 4/11/14, Ivan Kalvachev <ikalvachev at gmail.com> wrote:
> 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.

Vittorio Giovara,
Would you please give back some answer.
Even if you have given up, please tell us that you have given up.

I hope I haven't offended you in some way.


More information about the ffmpeg-devel mailing list