[FFmpeg-devel] [PATCHv3] On2 VP7 decoder

[Vittorio Giovara]

On Sun, Mar 30, 2014 at 12:31 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Sat, Mar 29, 2014 at 05:24:03AM +0100, Vittorio Giovara wrote:
>> On Fri, Mar 28, 2014 at 3:14 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
>>
>> You definitely are a Libav user, as is every ffmpeg developer and
>> user, as you merge every day whatever change Libav provides.
>> The fact that you can accept
>
> thats a game of words where you use a different definition of user.
> also called a strawman argument

No, you decided to be a Libav downstream (and can't deny that) but
take any occasion to bash Libav itself and its developers. You don't
like that, so you have no other option than insulting and criticizing
Libav devs (like you do below), so maybe it's you... grasping at
straws ;)

> Noone disputes that people using FFmpeg also use code developed by
> libav developers but that doesnt imply that they use the
> unmodified libav.

Say what you want, ffmpeg is still behaving like a bad downstream that
doesn't propagate patches upstream and harms users and devs for its
own childish benefit.

>> > I did very rarely test it for sake of an argument or for some
>> > statistics only ...
>> >
>> > So really the only place i could find an issue is in ffmpeg and
>> > if i do, it goes either as bugfix patch to the ML, as bugfix commit to
>> > git master, as ticket to trac or on my todo list for doing one of the
>> > previous once i have time
>>
>> The point is that this daily merge from Libav to ffmpeg also allows to
>> fix bugs sometimes and this is good, but the problem is that these
>> seldom bugfixes remain here while they should be reported to the
>> original author at least. This should be done in the spirit of open
>> source contribution, not in the "my project has more features and more
>> bugfixes".
>
> Lets see
> FFmpeg merges from libav the commits as they are and we fix issues
> in them as seperate commits on top of that. Keeping the code that
> was taken from libav and each change on top of that seperate.

And, don't forget, you are also increasing your commit count so you
can brag that ffmpeg has higher number of commits and (more
importantly) you're not sending the patches upstream where they could
be shared with other users.

> OTOH
> Libav takes code from FFmpeg and rebases and stashes fixes and
> improvments together so that noone can afterwards easily see what was
> changed and why.

Nice troll attempt, but won't work. Rather than having an horrible
source history like ffmpeg where you see every commit alternated with
a merge (btw why the name qatar? are you afraid to use Libav name?)
and makes git blame/history tracking MUCH harder, Libav prefers to
have linear history with *single* *atomic* patches (as much as
possible). This is so that you can see what's changed in a single
revision, rather than having to navigate countless (and possibly
distant) commits.

> Just as an example from the last 2 days you can take a look at:
> The brender pix decoder in libav:
> https://github.com/Libav/libav/commit/ae17878fb2ab100264226c84c58f5b95a703312f
> compared to the original that was in ffmpeg before:
> https://github.com/FFmpeg/FFmpeg/blob/68014c6ed98b5c90f4dc211429dd269ac727be4b/libavcodec/brender_pix.c
>
> FFmpegs changes on top of what i merged back from libav:
> https://github.com/FFmpeg/FFmpeg/commits/bcd5fd5346be263162792be595eff9fc08e5c853/libavcodec/brenderpix.c

Yes, you're welcome for my bugfixes, no need to thank me.

> so really, libav seems trying very hard to make their changes unuseable
> by ffmpeg while OTOH it seems seperate commits for each fix in ffmpeg
> arent enough for libav to use them.

Oh, they are quite useful to you, otherwise you'd not spend so much
time merging them. At the same time merging makes backporting *much*
harder so that Libav cherry-picking from ffmpeg takes much longer than
merging from Libav. So kudos, I guess?

> its probably not very diplomatic but IMO, if you fork another project
> you should accept that if you dont merge all changes that you wont
> have all changes then and that the extra work that choice causes is
> your problem.

Maybe you have a different definition of "fork", but the kind of fork
that took place between ffmpeg and Libav means that the two projects
didn't want to deal with each other any more. Libav mostly complied
with that, whereas ffmpeg seems to be leeching on every change brought
in by it, complain about it, and then not sharing the features or
bugfixes with it.

The open source movement is successful because of sharing and of
diversity, not conformity and silly competition. Maybe you should be
accepting the fact that ffmpeg is a Libav downstream and either stop
merging code and live on your own or start sending patches for the
benefit of both projects.

> And yes i would suggest that all libav developers just join ffmpeg,
> end the split and noone has to do duplicate work, testing and
> reporting.

Cool, that must be the reason why every new Libav contributor gets an
email saying that it's useless to contribute and that ffmpeg is so
much better, so they should be contributing to it instead.
I think the exact opposite, since ffmpeg merges everything from Libav,
there is little point in sending patches to ffmpeg in the first place,
but I also think that everyone is free to do whatever they want, so
I'm totally fine with that.

> Even more ironic, iam sure most libav developers would be happier had
> the fork never happened but it did and now people seem stuck in that
> split ...

Libav developers are quite happy thanks, but would probably do better
without the insults, trashing and bad PR received here for no
particular reason. Ironically I am sure most ffmpeg developers would
be happier if the continuous merging would not continue.

Incidentally I think that everyone would have been happier if you
respected the rules and stepped down as project leader when the
majority of developers voted against you back then. That would have
most likely prevented the fork in the first place...


Anyway, as I said in my previous email this is way off topic, and the
discussion is not leading anywhere, so I recommend continuing off list
if anyone wants to.
Cheers,
-- 
Vittorio