[gst-devel] Required GLib version policy

[Tim-Philipp Müller]

On Fri, 2009-02-20 at 18:50 +0100, Thomas Vander Stichele wrote:

> > Put differently (in good advocatus diaboli spirit): why should we/I care
> > about something that inconveniences you / a small fraction of our end
> > user base, but doesn't really pose any problems for you that can't be
> > overcome? When it could make my/our life easier?
> 
> It's a chicken and egg problem. 

Not at all (see below). It's just about finding a reasonable trade-off
that makes everyone equally unhappy.


> Why is that user base small ? Because
> you make it hard for them to be big.
>
> If you apply this reasoning, why are you allowing the inconvencience of
> changes made to support Windows and MacOSX ? 

Because cross-platform support is part of our mission statement; we
care, because we just do. Yet still, somewhere we draw a line, like when
it comes to Windows 95/98.


> Our user base is much smaller there than on Linux.

My argument wasn't about numbers at all.

It was about how far we want to go to accommodate rare/unusual
deployment scenarios, and where to draw the line when it comes to the
glib version required. Not more, not less. There are only so many people
who feel like they have to run bleeding edge GStreamer on a
many-year-old distro release (for good reasons, I'm sure).

I saying that it's ok to ensure those people can still deploy a bleeding
edge GStreamer on their many-year-old distro without too much additional
effort, but that it's also ok if stuff doesn't work for them out of the
box any longer (ie. with the glib version that happens to get shipped
with that).

(According to some statistics I just made up, 99% of our users use the
GStreamer packages that get shipped with their distro, whether it's
debian, fedora, ubuntu, RHEL, or whatever.)


> You're assuming the problems can't be overcome, [...]

I admit I am (based on experience or at least hear-say thereof). You
seem to imply by your choice of words that this is not the case; if so,
care to elaborate?


> [...] and it's about as valid as them assuming your compatibility
> problems can't be overcome.

All points of view are 'valid' in a technical sense. Of course these
issues can be overcome on the GStreamer side as well. We could have
stayed with glib-2.8 or glib-2.4. At some point it just becomes a bit
tedious, and it hinders progress (at least for those who actually
actively work on GStreamer, add features, debug stuff, help people on
irc, triage bugs, that kind of thing).

Making GStreamer rock is more fun than doing backwards compatibility
maintenance. GStreamer hackers leaning more towards one than the other
would be more than just 'valid'.

So it's back to finding a reasonable compromise. Hence my suggestion. I
still think it's a reasonable trade-off.


> Thread fixes are a strawman - we've had thread problems with pretty much
> every GLib series we've used, so you're going to be able to pull that
> one out basically forever :)

True. And some is unlikely to ever get fixed because the GLib folks in
question don't care. But that doesn't mean stuff actually improves over
time. Because it does. And it makes supporting people, ie. random people
on irc or with problems in bugzilla, easier (like when you're helping
someone debug a problem on their embedded system, and 45 minutes later
it turns out they were using glib-2.12 and running into a bug we know
has been fixed for ages in later versions).

In any case, it was just an example why our ancient GLib requirement is
not all that clever. Of course if you're an insider you know this stuff.
Outsiders will just think "Oh, 2.12 must be ok, let's use that
then." (Some may even think it's the recommended version 


> I think you should just evaluate on a case-by-case basis. Only when you
> have a good enough argument to upgrade to glib (the cost of not
> upgrading outweighing the benefit) should you do it.

This sounds very neat and commonsensical, but is really highly
impractical (see this discussion and the last one and the one before
that). Not least because there are close to zero costs to me and most
active GStreamer hackers, but lots of benefits, while the equation is
the other way round for people on the other side of the fence.

I can find something I want to make use of in GStreamer in almost every
single major GLib release. And that's just me. Do we really want to have
this discussion every 6-12 months?

I also think there's a value to things like the GLib requirement being
predictable. With something like the policy I suggested everyone can
plan in advance and everyone knows what the GLib requirement will be in
the next 12, 18, or maybe even 24 months.

Cheers
 -Tim