Ubuntu renaming FFmpeg to libav

Sat May 28 18:43:48 UTC 2011

Hi Reinhard, Hi Kees

my reply is below inline, and some of it probably uninterresting for
Ubuntu. But i felt i should correct statements that arent exactly
correct even if probably of no relevance to the technical board.
I appologize for wasting your time with this.

On Sat, May 28, 2011 at 09:39:52AM +0200, Reinhard Tartler wrote:
> Hi Kees,
> 
> On Fri, May 27, 2011 at 02:04:32 (CEST), Kees Cook wrote:
> 
> > Hi Reinhard,
> >
> > The Ubuntu Tech Board would like to have more information about what is
> > happening with FFmpeg and libav. Can you shed some light on this from the
> > perspective of being involved in the Debian and Ubuntu renaming of ffmpeg
> > to libav?
> >
> > BTW, I have no intention of trying to incite a flame war; we are just
> > interested in getting both sides of this story so we can better understand
> > what is going on.
> 
> Sure thing.
> 
> As you've probably guessed, the former FFmpeg development community is
> clearly split in two camps, 'FFmpeg' on the one side and 'Libav' on the
> other side. It is quite difficult for me to engage this discussion
> without getting into flames, as everyone here is pretty much biased.
> 
> The developer community split is the result of various flamewars and
> smaller fights that have been going on for at least five years, if not
> longer.

so far i agree, though the fights where of technical matters years ago.

> I'll refrain in this email from exact references as there is a
> significant risk of degenerating into mud-throwing, but I think I still
> have to explain some background first.

In the past (> 1 year ago) claims against me where raised on at least
one occasion that with public scrutiny where found out to be false.
It was about policy violations that turned out to be people mixing
x264s and ffmpegs policy up in their heads and seeing that they
followed that mix but i didnt. So i got vaguely accused of violating
it.

Now since the fork all public scrutiny is avoided by libav devs with
arguments of avoiding flames.

[...]
> upstream development community. At that time, the general attitude
> towards binary distribution of ffmpeg packages was, well, let's say
> reluctant, and indeed, on various occasions Michael as project leader
> argued on various occasions that it was in fact a bad idea to include
> ffmpeg in distributions such as debian and similar to begin with, and
> users are strongly encouraged to compile themselves.

Uhm, now this is really quite a bit missing the truth.
You mix various things here

I was against us distributing binaries out of fear from getting into
some software patent lawsuite. I likely did never state this in public
though

I was definitly in favor of distributions having ffmpeg packages.
And users where encouraged to compile themselfs because the distro
packages in debian where years behind. Also there where no volunteers
to handle bugreports against them

I was not volunteering to work on ffmpeg releases myself previously but
now do work on them, we are working toward a release which should be
out in the next days and have release candidates on our download page

> With a considerable
> amount of effort and with the help of Diego Biurrun, we've managed to
> reinstantiate formal releases and release branches to help distributions
> such as Debian and Ubuntu with maintaining proper and reliable
> distribution packages.

you did alot and great work on the releases in the past and i would
welcome you doing it (with help from me of course) on ffmpeg.org
releases again. But i said this already

> 
> Earlier this year, a group of FFmpeg developers gathered and discussed
> the future and their involvement, which eventually ended in creating the
> fork Libav. Clearly, this process was not without faults and certainly
> could have been handled better, but in the end, this result was
> (unfortunately) unavoidable. We, the Libav developers, see similarities
> to former development forks such as the infamous XFree86/X.org fork or
> the gcc/egcs split. And indeed, just like the egcs story, ideally the
> two projects can merge again in future, but at the moment, that's pretty
> much out of question.  The main reason for forking was Michael
> himself. On various occasions his quite strict rules on code quality and
> reviews doesn't seem to apply to him, while important developments, such
> as ffmpeg-mt, have been stalled basically for years. Indeed, Michael
> even stated a few days before the fork on IRC 'ill never merge -mt'.

I just wanted to say "outright lie" then i checked the log and did
ROTFL
reinhard, we need to meet and you need to learn austrian humor
heres the full quote:

Jan 31 13:20:31 <elenril>       how about the following compromise: 1)you merge ffmpeg-mt 2)i send you some good chocolate
Jan 31 13:20:50 <kshishkov>     elenril: you'd fail at 2 definitely
Jan 31 13:21:07 <michaelni>     russian chocolate? !
Jan 31 13:21:15 *       michaelni will never merge ffmopeg-mt

elenril (anton khirnov) is russian and if someone wants  me to eat
russian chocolate ill definitly will do the opposite
of what he wants me to do.
Thus the "never merge ffmopeg-mt" was a joke

about merging libav & ffmpeg again, i agree this would be ideal.
especially merging the communication channels even if the repositories
stay split.

> 
> After the fork, Michael has insulted almost everyone involved with
> founding Libav at least once, used libel and death threats as 'jokes',

ill leave it to you to back that claim up.
Jokes i did make, libel not and death threats neither. Insult some
people, maybe, i wont deny this, iam an abbrasive guy sometimes.

> but OTOH keeps merging the work done at Libav both with and without
> insults.

> Interestingly, his standards and attitude to external work have
> totally changed: He has committed his mplayer filter wrapper despite
> predominant rejections,

I admit full guilt of adding features
besides the mplayer filters commit was before the fork.

> ffmpeg-mt has been merged (partially with wrong
> attribution!)

I did a normal git merge but people where enraged and mad at me because
that pulled too much messy history in, so we quickly reverted that and
i just commited the change like a normal change, because it was done
in a hurry and had to be done quickly to minimize disruptions of checkouts
it wasnt worded as good as it should have been clarifying authorship.
I did checkin the full commit log of ffmpeg-mt when ronald pointed the
problem out

Besides, if wanted, i have a few commits from libav that where also
misatributed. I though currently belive they where just mistakes or
coincidences and not intentional.

> despite various tests still failing (when running them
> with more than one thread),

new code not working with all new tests, yes

OTOH libav added lots of changes to libswscale that make it just
segfault a few days ago, that is, "things that worked before
not working anymore" and IMO that is worse.
Even more so when after 5+ commits that should fix it, it stil is
not working
And i asked people to give me a chance to review changes
to swscale before they are commited, its my code, i wrote like 95%
of swscale. i know it and its messy code that needs reviews by
someone who knows it.
and then when i point it out in public that ronald broke it again
people say iam insulting.

> just to name a few.  Now he argues that the
> merged external branches make 'his' tree 'superior'.

Its not just external branches, there are hundereads of commits
that add features and bugfixes that have never been merged into
libav.org

> 
> I as Debian and Ubuntu packager of the Libav/FFmpeg packages need to
> balance what line of development is going to be more sustainable in the
> long run. If you look at the git commit statistics, you'll notice that
> the developers with most commits (both numbers of commits and lines of
> changed code) in the last year and three years before the fork are in
> the Libav camp now. While Michael clearly has written most of the code
> in FFmpeg, I fear that there is a considerable bus factor on that
> side.

I didnt participate in all the huge recent cosmetic cleanups, function
renamings and such stuff.
Also prior to the fork, fights made me loose interrest a bit and
become less active. (that is the last year or so)
besides if you counted commits where are the numbers?

> Moreover, my experiences with discussing matters like symbol
> versioning and binary compatibility with him doesn't make me too
> enthusiastic about maintaining a package with him as upstream

you refer to me finding several bugs in gnu ld.so i think.
amongth them where assertion failures.
IIRC you where more annoyed by me finding the bugs than there being
bugs. My oppinion was the bugs should be fixed upstream but i wasnt
volunteering to contact drepper. And that the whole symbol moving
betweem .so used by distros could be simplified alot where they fixed.
Your side IIRC was that its all too big and too much could break if
anything was changed in ld.so besides IIRC mans argued it was pointless
because it would take 10 years before it was available.
I remember arguing its better if its available in 10 years than never

also afterward mans (of libav.org) team removed all references that i
added in our documentation to these bugs. I still havnt added them
back to ffmpeg.org so as not to piss the libav side off more.

> in Debian
> or Ubuntu. Libav on the other hand is a group of very nice developers
> that generally are very open to discuss issues with API and ABI.

[FFmpeg-devel] ABI and forks

[FFmpeg-devel] [PATCH][RFC] ABI/API compatibility between forks

both started by me, both ignored by libav people

[...]
> What I consider most important for Ubuntu is that Libav has me as active
> release manager that drives a) daily builds in ubuntu [libav:daily], b)
> beta releases that are also included in other distros such as Gentoo
> [libav-beta:Gentoo] and of course c) proper 'main' release
> branches. Michaels idea of always using the latest git master code OTOH
> just doesn't work in binary distros with long-term stable
> releases. FFmpeg on the other hand seems to me these days mainly as
> one-man-show. While FFmpeg is clearly receiving more drive-by
> contributions, ffmpeg-devel still contains a considerable amount of
> flamewars, while libav-devel has way more technical reviews and
> generally seems to me the nicer group to work with.

reminds me of alex telling diego "have a nice day" on libav-devel after
diego requireing alex to change copyright statements of other people as
a condition for inclusion (removing ffmpeg and putting libav there,
dunno if thats ok or not but alex didnt seem to feel it was ok and i
tend to ask people (like i did with vitor) before changing libav
to ffmpeg)

but now all my email addresses seem banned so i cant
subscribe and read libav-dev anymore easily. My main email address was
banned since the libav-dev list was created, the other since i sent
a reply to ronald personally to a message from the list
and noone of libav
explained me why i was banned and i CC-ed my question about it to half
of the libav developers if not more.
maybe you can explain it here to us why and by whom?

And technically, its not good to ban the main author from the main
development channel. It doesnt help code quality not to mention, its
not exactly what i call friendly

> 
> [libav:daily] https://launchpad.net/~motumedia/+archive/libav-daily/+packages
> [libav-beta:Gentoo] http://packages.gentoo.org/package/media-video/libav
> 
> If you have any further questions or would like to see references as
> backup for my claims, I'm happy to send them to you in private in order
> to avoid igniting additional flamewars.

Private statements without giving the person / project about whom these
statements are a chance to comment.

> Additionally, please feel
> invited to talk to other Libav developers on IRC, via private email or
> via phone directly if you feel that you need to hear more opinions on
> the issue.

They all hate me. I can already confirm that ;)
why they do, that i dont know

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20110528/7384fc79/attachment-0001.pgp>