[gst-devel] [gst-cvs] thomasvs gst-ffmpeg: gst-ffmpeg/ gst-ffmpeg/ext/ffmpeg/

[Benjamin Otte]

On Wed, 14 Feb 2007, Loïc Minier wrote:

> On Wed, Feb 14, 2007, Edward Hervey wrote:
> >  Since ffmpeg doesn't want to do releases, I think we should *play the
> > same game*. Namely : gst-ffmpeg cvs will only work with ffmpeg svn.
>
>  I think it would put gst-ffmpeg in a better solution than it is now.
>  Concerning dists, I can imagine the development cycle in distros would
>  go like this:
>  1) new ffmpeg snapshot gets uploaded to $dist
>  2) gst-ffmpeg gets bug reports in $dist that it doesn't work
>  3) new corresponding gst-ffmpeg snapshot gets uploaded to $dist
>
>  Which is acceptable IF we have: a) a responsive gst-ffmpeg maintainer
>  in $dist and b) an always up-to-date gst-ffmpeg upstream (that's you!)
>
If you have a package that breaks API, ABI and features any day they like
and don't even provide a way to detect that, there's not much you can do
about it when you depend on it. It'll always break and it'll always be
annoying.
In the SVN tracking case you treat every SVN commit to ffmpeg like a
major release and that's definitely not what you want. What will happen is
that you will end up with a revision X, because that's what xine want. And
then you figure out that gst devels fixed gst-ffmpeg for revisions
X-32 and X+27, swfdec works with X-24 and X+39, Kino requires X-17 or
X+12, etc.

The only chance around this is to get someone somewhere to do
regular releases (ideally tested, but just releases with a useful
version number would be fine.) Then you make distros and downstream
follow these releases. If you can't come up with someone doing them you
can just say "SVN at 0:00h 1st of every odd month" or something
(depending on how often the distros want to update their snapshots) and
set the version to "$YEAR.$MONTH". Then you just need to make sure livna,
Ubuntu and Debian all ship exactly that SVN commit and the magic
automatically happens, because suddenly developers can depend on these
versions and easily detect them in configure scripts.

>  However, I would like to mention at least one other development model
>  I've seen to handle a similar situation: mozilla and derived browsers.
>  Galeon and Epiphany developers have put a LOT of efforts in supporting
>  API breakages as they appeared in Firefox/Mozilla/XulRunner/SeaMonkey
>  releases.  The development process was something like:
>  1) build galeon against all known development trees and latest tarball
>     releases in each branch
>  2) add configure checks each time a new build failure occurs to detect
>     the API change and add #ifdefs to support both the new and the old
>     API
>
The nice thing about this is that there's only 10 different versions they
track. 10 different SVN versions in ffmpeg happen in what, 1 week?

>  Well, since you seem to be open to hear crazy things, what about you
>  play exactly the same game as the distributors and simply provide
>  *ffmpeg* packages along your gst-ffmpeg packages?   :-)
>
>  Basically, take the latest ffmpeg, apply the patches you still want to
>  add (which remain from your list), change the version string to
>  ffmpeg-by-gstreamer-folks-officially-supported and ship the ffmpeg +
>  gst-ffmpeg combo instead of simply gst-ffmpeg.
>
This is a bad idea, unless GStreamer wants to become the new ffmpeg
maintainer. Because if someone ships an ffmpeg to me and it works, I'll
use that one and file bugs against GStreamer's ffmpeg. ;)


Benjamin