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

[Thomas Vander Stichele]

Hi,

>  Out of the patches currently in our mirror , we have:
>  * one for implementing autotools support. Well ffmpeg has got a
> simili-configure script which does enough (has the options we need).
>  * one for not installing some libraries/tools. Same thing, we can
> configure ffmpeg in the same way.

AFAIK the plan was always to develop these patches then send them
upstream.  The autotools one was commited upstream I think (Ronald ?),
and so could be removed.

>   I seriously disagree that having those patches (mostly unneeded, or
> that should be commited upstream) and the burden a maintaining a
> mirror outweighs just checking out a specific revision of ffmpeg and
> spending some time insisting on some critical patches going into
> ffmpeg.
> 
>  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.

I think this idea conflicts with what you said above.  Either you pick a
specific revision and fix bugs against that to avoid regressions, or you
track svn, in which case you are *forced* to take the regressions.

The goal of this game is simple: deliver gst-ffmpeg modules of ever
increasing quality without any regressions.  Whatever system that makes
this the easiest is pretty much fine.

Tracking a specific revision with which we work (which is what we used
to do *before* we allowed compiling against external ffmpeg) is one way
of doing that - you theoretically mostly have patches to fix regressions
they have in their upstream.

Tracking TRUNK is guaranteed to give you regressions, doesn't sound like
a good idea to me.

Both are orthogonal to the issue of "do we actually submit our patches".
But in the end, the proper way to maintain local patches for a
non-trivial amount of time is to maintain these patch sets as separable
entities.


>  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.

Not sure how your idea solves the distro problem ? If gst-ffmpeg always
follows trunk, they won't be able to pick a release that matches
whatever snapshot they took any more than when we pick a revision for
them.

> 
>  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.

API/ABI is the least of our worries.  Sure it is annoying, but you get
told at build time.  The worry is about feature regression.

Thomas