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

[Loïc Minier]

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.
> Then when we do (pre-)releases, we mark which ffmpeg revision number
> that release was done against and ffmpeg will ONLY be able to link
> against that specific version. This might require not updating our
> dependencies
>  This comes to the same as having a mirror... without all the hassle
> of maintaining it our side. It would then be up to distro packagers to
> take the burden of making sure which release/revision of gst-ffmpeg
> they need depending on what ffmpeg version they have installed
> system-wide.

 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!)


 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

 For example:
 <http://patches.theflowerdays.com/tinderbox/>

 Yes, it resulted in a crippled configure.ac:
 <http://svn.gnome.org/viewcvs/galeon/trunk/configure.in?rev=8905&view=markup>

 But IMO the maintenance burden is sufficiently close to simply fixing
 the API breakages to warrant the efforts.  Since these are mostly your
 efforts, it's obviously up to you to decide how old ffmpegs you want to
 support!  :-)

>  Also, it wouldn't be too much trouble creating a build-slave that
> compiles gst-ffmpeg against a trunk checkout of ffmpeg anytime there
> is a ffmpeg commit. This would enable us to figure out as early as
> possible when there is a change in the API/ABI and change gst-ffmpeg
> accordingly.

 Excellent idea, which has proven successful against the Mozilla code
 base!

>  In order not to penalize people following our releases and so
> tracking bugs doesn't become hell, we would bundle the ffmpeg svn
> checkout that we known works with the given release, in more or less
> the same way it is done currently (replace checkout of the mirror by a
> specific revision checkout of ffmpeg), and we would ONLY support
> gst-ffmpeg bugs built with that internal ffmpeg. Up to the package
> maintainers to triage bugs their side, check they can reproduce those
> bugs with a support gst-ffmpeg, and then post bugs upstream.

 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.

 The benefits I would see for this approach: you truly decouple
 gst-ffmpeg from ffmpeg but you still maintain a tested "official"
 ffmpeg, and you also have a setup very similar to the setup of
 distributors.  This also means you have only one type of linking to
 support (external ffmpeg).

-- 
Loïc Minier <lool at dooz.org>