[gst-devel] GStreamer status, 20 Sept 2005

[Bastien Nocera]

On Thu, 2005-09-22 at 15:34 +0200, Thomas Vander Stichele wrote:
> 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.

Those are minor niggles. Look at the bugs being reported against the
GStreamer backend, most of them are crashers, deadlocks or playback
problems that we get from GStreamer itself.
Regressions from minor version to minor version of GStreamer (ie.
getting testing for new 0.8.x "stable" releases) and fixing crashers is
what you should be concentrating on. There's no need to upgrade Totem to
fix those, and there are plenty of people that are happy with their
out-of-date Totem, as long as the underlying backend is new enough to
fix those problems.

Using the latest CVS from Totem is not necessary to test the GStreamer
backend, and most of the GStreamer issues.

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

You're talking about a pre-1.0 version. 1.0.0 was not perfect, which is
why we had 4 releases afterwards. So it is true that the development
version of Totem needed a development environment at the time.

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

Most of the bugs were not in Totem itself, but in GStreamer. A test
suite that just tries to play a bunch of files using playbin and
gst-launch would have more impact on the user experience than Totem
testing. Minor niggles like being able to switch visual plugins on the
fly are hardly what is going to impact on the user experience.

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

I wasn't commenting on whether GStreamer should be doing it that way, I
was answering to your attacks on the Totem development model which were
mostly unfounded, or at best misinformed.

---
Bastien Nocera <hadess at hadess.net>