[Ffmpeg-devel] Using ffmpeg libs in an OSS project is a nightmare
Sat Aug 6 13:15:37 CEST 2005
>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
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
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
>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
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 at lavrsen.dk
Home Page - http://www.lavrsen.dk
More information about the ffmpeg-devel