[gst-devel] GStreamer status, 20 Sept 2005

[Thomas Vander Stichele]

Hi,

> > In other changes, Stefan Kost checked in a patch to use GLib 2.8's
> > atomic refcounting for GObject, which was something Wim pushed hard for
> > in GLib's last development cycle. Of course, we still support the hacks
> > that allow GStreamer to work reliably with GLib as old as 2.4, but you
> > have to be careful when getting an object from GLib, as with
> > g_value_get_object.
> 
> What's the reason again why we don't bite the bullet and require
> GLib-2.8 from the start, which would be nice for other things as well?

Because there will always be *something* we could use from a newer
version and hence there will always be a reason to use latest cvs of
everything.

As the case with Totem has proven abundantly, all this guarantees you is
that no significant amount of users will ever end up with something that
they can install and that works.

That's why over the years I've pushed for making sure you can at least
install what we're doing on the last stable version of important
distros, possibly with some minor upgrades that don't affect the system
too much.  This allows for quite a bit wider testing by people that are
willing to try out some apps and give us some feedback, but aren't
willing to check out 15 different modules from CVS to do so.

I'd be ok by now with upping the requirement to maybe glib 2.6 because
of the sanity check mentioned above, but there are very few stable
distros who ship with glib 2.8.  And even when they do, we're still
going to uncover bugs in that version of glib as we go along that we
can't yet get fixed and to users.


> It's not like people can't safely upgrade their GLib-2.x to 2.8 without
> stuff breaking (on Linux at least),

You'd think, but this isn't always the case.  Hence users typically feel
very uncomfortable upgrading packages that aren't published by their
distro.  Think about it this way - if Red Hat or Ubuntu aren't upgrading
between minor versions of these libraries, why should users ?

Adding that requirement will cut back the number of available testers
significantly.

>  and we are already adding all kinds
> of utility functions

"all kinds of" is probably a bit overstated :) what it comes down to in
the end is an exercise in balance between "how much does it cost to
support something that is not the latest and greatest" and "how much do
we gain from getting a lot wider testing for things".

Speaking with a company hat on (I'm sure ideas coming from both my
release maintainer side and company side will overlap at times), we're
also working a lot on 0.9 and the reason we as developers can do this is
because we're pushing for it to be used on actual products we're
writing.  If the product we're writing becomes impossible to install due
to CVS deps of everything, I don't see us being able to make a
convincing argument for basing our work on 0.9 - which would cut back a
lot of the time we're investing in 0.9.

Momentum on a devel branch comes from various different places, and the
idea is to balance the speed with the friction and come out ahead :)

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Don't shut your eyes just yet
Don't even open your mouth just yet
Because there's things you've got to see
There's things you won't believe of me
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/