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
signature.asc
Description: Digital signature
-- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
