[Ffmpeg-devel] Using ffmpeg libs in an OSS project is a nightmare

[Kenneth Lavrsen]

>distributions which are far behind cvs head or even have just the yearly
>releases are not supported in any way by me/us? and i dont care at all what
>happens to them, these old releases have _known_ security bugs and any work
>toward making them more useable is work toward getting the users systems
>hacked, thats not something i want to contribute to

Distributions in general do not contain ffmpeg for patent reasons. That is 
why rpms are made by people outside USA by people independent from the distros.



> >
> > I get support questions daily related to ffmpeg. I am so tired of this
> > situation. And I am sure maintainer of other project feels like I do.
> >
> > 90% of users download and install an RPM. Only few install from sources.
> > And then it always ends up with downloading some RPM from Dag, or ATRPMs or
> > Livna and then things break. MPlayer does not work or Motion does not work.
>
>well you are ignoring the suggestions of both the ffmpeg & mplayer developers
>and then complain that libav*+mplayer breaks what do you expect?

I am not ignoring anything. Installing RPM packages is the way 90% or maybe 
rather 99% of users install and run software. Especially libraries.
And WHY should your little project as the only one be so different from the 
others? Why are you right and the whole open source software world in 
general so wrong?


> > All the time because you guys change the API for the libs more often than I
> > change my underwear
>
>ok thats the first valid complaint in your mail, we should really try harder
>to avoid api breakage

You bet!
But as a programmer and project maintainer I also know that sometimes it is 
necessary. And when I decide to change the API - I do it in an announced 
and controlled manor.
Example. When Motion changed its remote control interface (used by any GUI 
frontends) I announced my intentions many months before, wrote a new API 
doc that was reviewed (announced to mailing list - nothing fancy here) and 
when implemented Motion changed version from 3.1.17 to 3.2.1. And I even 
continued the 3.1 branch a few extra minor bug releases until 3.1.20 when I 
finally declared the old branch dead. That is called change control. That 
is called caring about the users and the programmers that work on projects 
that depend on yours.

>there are release notes, they are called cvslog, if you dislike that, just
>volunteer to write better ones for the cvs snapshots, and just to preempt the
>obvious troll, the number of changes in the snapshots are the same as in
>releases over time X so its not really more work

Noone needs the detailed changes. You need to summarise the changes.
You know dammed well that CVS log entries are made to be understood here 
and now by the other programmers.
ffmpeg is just one little package that Motion and other projects rely on. 
You cannot expect us to sit and read 1000s of CVS entries and try to 
decipher what that means. It is totally unrealistic.
If you work on a project and maintain it - you should spend the extra 30 
minutes per 3 months and summarize the big picture. Ie. feature changes - 1 
line per feature - and API changes - 1 line per change. Simple. And only 
the maintainer with the overview can realisticly do it.


>calling a random or not random snapshot every 3 month a release will IMHO not
>help much, you still have to deal with every single API change and thouse who
>use cvs or a non release snapshot will have a lot of problems, now thouse
>using cvs are the developers and they are much more important then the users
>simply because a project with no developers is a dead project, it depends
>upon them

developers are more important than the users??
You really mean that? ffmpeg without projects that uses the project is a 
command line tool and a set of libs. The many nice projects puts it to 
life. You should be proud that the work you have done is now used by so 
many different projects. And it is a real wonderful project you have made 
from technical perspective. Some really cool brains are behind the  many 
codelines in ffmpeg.

You should really care about the developers of the projects that uses 
ffmpeg. We spend a lot of time on our projects too you know.

>the real problem are the API changes and the fact noone cares about the 
>shared
>lib support (we just have an army of trolls complaining)

You have an army of trolls complaining. Maybe you should start listening 
and ope your ind to the fact that maybe they are all right. I am not a 
troll. I am an open source developer who maintains TWO open source projects 
(Motion and Open2300) and helps with documentation on the PWC driver. I 
spend 2-3 hours a day on open source development. And often 8 hours a day 
in the weekends and vacations. And it is not my daytime job. I have a full 
time job on top of that. I am not paid either for my work. And I do not 
even accept donations. I think I am doing my share for the open source 
community and do not need to be called a troll.

I am sure that making 3 releases per year would cost you less time to do 
than answering emails when "trolls" try to convince you to run your project 
a little more adult way.


>furhermore ffmpeg is a free software project developed by volunteers, if you
>want something done/changed/... the first and absolutely necessary thing is
>to volunteer to do the related work, you cant expect us to do what you want
>for you for free

As I already wrote above. I am doing my share to the open source community.
If you need a helping hand to upload the files to Sourceforge 3 times a 
year I think I can find the time for that. That is easy. I just need to 
know which daily snap is the best from the previous few days. Or we could 
put recommendations from developers on a Wiki page.

I can also make a few topic on my TWiki where developers can add a line now 
and then for the release note and for voting for best release candidate.
But I really do not think this is a problem with human resources or anyones 
time. It is a lack of understand of basic version control and its importance

I would like to hear the oppinions from other developers of projects using 
ffmpeg.

Would a fixed release schedule - let us say February 1st, June 1st, October 
1st where you know there is a fixed release be someone that would be useful 
and helpful to you?
(naturally one can delay it a few days if a severe bug has just been found 
and needs to be fixed and naturally one can do a quick follow up release if 
something really serious is broken. But something is always broken. And if 
it is a problem - the support answer will always be to download latest CVS 
snap. Noone will fix an old version.).

And to the developers of ffmpeg - would that really disturb your sleep 
knowing that every 4 month you work gets released with a new version number 
and a bunch of packagers create their packages for RH, Fedora, Suse, 
Gentoo, Debian etc etc?

And if any packagers are following this mailing list - would you prefer to 
package these scheduled releases instead of some random daily snaps?

Kenneth


-- 
Kenneth Lavrsen,
Glostrup, Denmark
kenneth at lavrsen.dk
Home Page - http://www.lavrsen.dk