[gst-devel] GStreamer status, 20 Sept 2005

[Thomas Vander Stichele]

Hi,
 
> > 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

> Those are minor niggles.

Well, depending on what side of the fence you're on, but sure :) If the
player plays an Ogg/Vorbis/Theora stream without crashing, but it's
going completely crazy opening one from a live network stream, you might
feel this is a bug, and not a feature, especially if you're gearing up
for streaming a conference.

Anyway, agree with Ronald that those four things mentioned happen to be
enhancements, not bug fixes.  Most of the actual bugs are indeed in the
GStreamer backend, and I'm not debating that neither complaining about
it, because when those bugs got fixed I could ship the fixes.

Again - I am making a point about the things that make it hard to ship
fixes to users.

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

Yes, you're repeating my point.  I am talking about the period of time
between FC3 and FC4.  I know that today it is easier, and I trust you
when you say it will remain so.

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

You'd be surprised - a bunch of files played with different results
between totem and playbin.

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

I understand you're defensive about it, but it's not an attack.  I agree
I got "features" (which typically are in the Totem code) and "bug
fixes" (which typically are in the GStreamer code) mixed up, because
both were being discussed.  I am not attacking the Totem development
model, I am making points about why it doesn't work IMO for GStreamer.

Given that my basic claim about Totem's development all along has been,
in a nutshell, "code that went into Totem between FC3 and FC4/pre-1.0.0
totem was a lot less-tested by people because of the unstable deps", I
don't see how that is unfounded or misinformed.  It doesn't mean that
it's the wrong way to do it for Totem, or that it's not the same
situation for a bunch of other projects.  Regardless, it's not something
I want to have happen for GStreamer.

Anyway, if we want to hash this out further let's take it off-list.
This thread was supposed to be about glib 2.6 vs. glib 2.8.  If I
offended you in any way it was unintentional.

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
That's all changed for good
No more worries and doubts
The good will come out
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/