[gst-devel] GStreamer status, 20 Sept 2005

Thomas Vander Stichele thomas at apestaart.org
Thu Sep 22 06:36:59 CEST 2005


Hi,

> > > You can still install newer versions of Totem on FC4. The 1.0 branch
> > > won't require any additional dependencies
> > 
> > ... which is the branch that is not receiving that much bug fixing wrt.
> > GStreamer, right ? AFAIK you're not working on anything
> > GStreamer-related for Totem.
> 
> Most of the fixes go in GStreamer itself, not really in the GStreamer
> backend. Take a look at the commit messages in the ChangeLog, and tell
> me how much work was done on the GStreamer backend compared to front-end
> work.
> 
> All the bug fixes for crashers go to both branches, so whether you're
> using 1.0.x or 1.2.x, the only real thing that will fix bugs is a new
> version of GStreamer and its plugins.

Specific examples are things like:
- having visualizers
- being able to change visualizers on the fly
- providing information about how much network data is being buffered
when playing back from streams
- being able to set the size of this buffer

All of these that were worked on:
- are GStreamer-backend-specific
- didn't necessarily need that much change in GStreamer (changing
visualizers on the fly for example is not something that GStreamer made
impossible)
- all require changing code that lives in the Totem repository.

None of these, in the cycle between FC3 and FC4, were testable with
anything else than a CVS build of GNOME.  As anyone who tracks GNOME cvs
knows, it can take quite a bit of time to get a build where all required
modules are built in some form or shape.  This isn't anyone's fault in
particular, this is just how it is.

But the bottom line is - any sort of verification or testing on these
fixes was few and far between, and believe me, both Christian and me
spent quite some time on trying.

I'm not saying it is anyone's fault in particular.  It's just how it is.
I *am* saying, however, that this made it very hard for anyone who was
interested in testing and providing feedback to do so.  If you disagree,
feel free to do so, but there's no point in me trying to make my point
any clearer than this.  If you want to claim that it was easy for anyone
to check the bugfixes going in on these features, go ahead.

I am completely willing to believe that it's going to be different in
the future.  I am merely making the point, using an example from the
past, that relying on unstable code gets you sigificantly less feedback.

> > ... right, which is something a user typically won't do and which RedHat
> > won't provide as an update to FC4.
> 
> True, but that's something you would easily be able to push along with
> your Totem RPMs if you wanted users to test those on FC4.

Again, I'll reiterate - a significant amount of users *does not* want to
upgrade stuff like glib and gtk to the next minor number.  I could
provide *a lot* of things in our repo, and it would defeat the point -
since I would see 95% of those people not use the repo anymore.


And again, I am not trying to make a point about the way Totem is
developed, and whether or not it's the right way.  I'm simply using an
example to explain why I feel this is *not* the right thing to do for
GStreamer itself.

Thomas



Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
I can't leave you alone
because you're so disarming
and I'm caught in the midst of you
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/







More information about the gstreamer-devel mailing list