Required GLib version policy

[Tim-Philipp Müller-2]

Hi,

I think we should try to bump our GLib requirements more often. Slowly
and conservatively, but regularly.

To this effect I propose some sort of informal GLib version policy,
something like:

 - whenever we release core/base, we look into
   bumping the GLib requirement for core/base
   (ie. right *after* the core/base release, not
   for the release itself)

 - we then look at all (stable) GLib 2.N.1 releases
   that are older than ~12 months, and pick the
   highest N. That's our new GLIB_REQ then.

The overall effect would be that when we release the next core/base the
required GLib version would be at least around 15-18 months old, which
seems fair to me (and what I think emerged as acceptable consensus the
last time we debated this issue on the mailing list).

So:

 - GLib 2.N.1 would be at least 12 months old
   *when we bump the requirement* (at this point
   only affecting GStreamer hackers)

 - a core/base with this new requirement would
   be done ca. 3 months later, so at the time
   this new requirement hits GStreamer consumers
   and distributors the GLib version required
   would be at least 15 months old

 - any GLib 2.N.x series will typically be
   maintained and in use for 6-9 months (random
   info on the side)

Thoughts? Sound good?

Cheers
 -Tim



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Farkas Levente]

Tim-Philipp Müller wrote:

> Hi,
>
> I think we should try to bump our GLib requirements more often. Slowly
> and conservatively, but regularly.
>
> To this effect I propose some sort of informal GLib version policy,
> something like:
>
>  - whenever we release core/base, we look into
>    bumping the GLib requirement for core/base
>    (ie. right *after* the core/base release, not
>    for the release itself)
>
>  - we then look at all (stable) GLib 2.N.1 releases
>    that are older than ~12 months, and pick the
>    highest N. That's our new GLIB_REQ then.
>
> The overall effect would be that when we release the next core/base the
> required GLib version would be at least around 15-18 months old, which
> seems fair to me (and what I think emerged as acceptable consensus the
> last time we debated this issue on the mailing list).
>
> So:
>
>  - GLib 2.N.1 would be at least 12 months old
>    *when we bump the requirement* (at this point
>    only affecting GStreamer hackers)
>
>  - a core/base with this new requirement would
>    be done ca. 3 months later, so at the time
>    this new requirement hits GStreamer consumers
>    and distributors the GLib version required
>    would be at least 15 months old
>
>  - any GLib 2.N.x series will typically be
>    maintained and in use for 6-9 months (random
>    info on the side)
>
> Thoughts? Sound good?

why would you like to bump requirements version when even an older glib
can work properly? most enterprise distro has very old (in this sense)
glib, but gstreamer can work even with that version. eg rhel/centos-5
has only glib2-2.12.3. even with that version all of the latest
gstreamer can work. but if you bump version (without any good reason)
we've to hack the tarball to be able to compile the latest versions on
enterprise distros.
so i vote against it.

--
  Levente                               "Si vis pacem para bellum!"

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

On Thu, 2009-02-19 at 17:51 +0100, Farkas Levente wrote:

> why would you like to bump requirements version when even an older glib
> can work properly? most enterprise distro has very old (in this sense)
> glib, but gstreamer can work even with that version. eg rhel/centos-5
> has only glib2-2.12.3. even with that version all of the latest
> gstreamer can work. but if you bump version (without any good reason)
> we've to hack the tarball to be able to compile the latest versions on
> enterprise distros.
> so i vote against it.

So we can make use of all the new stuff that gets added to GLib at some
point (obviously); because it makes life easier for developers if we
can. It also decreases the divergence between a) the GLib version 99.9%
of the users use [the people who install Fedora/ubuntu/debian and just
use the version shipped with it] and that 99.9% of the GStreamer hackers
use, and b) the minimum version that's required. This has many
advantages, not least of them for debugging/bug triaging etc.

Other than features, there are a bunch of GObject thread-safety issues
which we can't work around fully in GStremaer and which are only fixed
in later glib versions than 2.12. Just as an example.

And: so we don't have to have this argument about whether the ability to
make use of some specific feature in glib is worth bumping the
requirement for all the time over and over again.

At the end of the day it's a trade-off between maintenance ease/burden
and convenience for consumers of GStreamer such as yourself. Following
your line of argument (it works now just fine), there'll never be a
really good reason.

There are very very few people that feel like they need to run a
bleeding edge GStreamer on top of a REALLY OLD distro release (I think
it's fair to say that something older than 18 months is really old in
open source land). Why can't you either (a) upgrade to a newer GLib
[hardly something that is likely to screw up your entire system], or (b)
build your bleeding edge GStreamer against a newer GLib in a non-system
prefix? These seem perfectly acceptable technical solutions to me, and
it seems to me like the only reason you're not in favour of my
suggestion is that it would inconvenience you.

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?

Cheers
 -Tim



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[michael smith-6-3]

On Thu, Feb 19, 2009 at 8:36 AM, Tim-Philipp Müller <[hidden email]> wrote:
> Hi,
>
> I think we should try to bump our GLib requirements more often. Slowly
> and conservatively, but regularly.

I've argued against this previously, but I think I've been
sufficiently convinced that the burden to users/developers is not
unreasonable, and the benefits sufficient, that this is a good idea.

>
> To this effect I propose some sort of informal GLib version policy,
> something like:
>
>  - whenever we release core/base, we look into
>   bumping the GLib requirement for core/base
>   (ie. right *after* the core/base release, not
>   for the release itself)
>
>  - we then look at all (stable) GLib 2.N.1 releases
>   that are older than ~12 months, and pick the
>   highest N. That's our new GLIB_REQ then.
>
> The overall effect would be that when we release the next core/base the
> required GLib version would be at least around 15-18 months old, which
> seems fair to me (and what I think emerged as acceptable consensus the
> last time we debated this issue on the mailing list).
>
> So:
>
>  - GLib 2.N.1 would be at least 12 months old
>   *when we bump the requirement* (at this point
>   only affecting GStreamer hackers)
>
>  - a core/base with this new requirement would
>   be done ca. 3 months later, so at the time
>   this new requirement hits GStreamer consumers
>   and distributors the GLib version required
>   would be at least 15 months old
>
>  - any GLib 2.N.x series will typically be
>   maintained and in use for 6-9 months (random
>   info on the side)

I _would_ prefer to see the requirement change a little less
frequently that this, though. Once a year, for example, rather than
twice a year. To give a concrete suggestion then: I'd change your
proposal to do this after every second core/base release.

I'm not going to actively campaign against your plan if you think this
is a bad idea, though.

Mike

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Sebastian Dröge-7]

Am Donnerstag, den 19.02.2009, 10:17 -0800 schrieb Michael Smith:

> On Thu, Feb 19, 2009 at 8:36 AM, Tim-Philipp Müller <[hidden email]> wrote:
> > Hi,
> >
> > I think we should try to bump our GLib requirements more often. Slowly
> > and conservatively, but regularly.
>
> I've argued against this previously, but I think I've been
> sufficiently convinced that the burden to users/developers is not
> unreasonable, and the benefits sufficient, that this is a good idea.
>
>
> >
> > To this effect I propose some sort of informal GLib version policy,
> > something like:
> >
> >  - whenever we release core/base, we look into
> >   bumping the GLib requirement for core/base
> >   (ie. right *after* the core/base release, not
> >   for the release itself)
> >
> >  - we then look at all (stable) GLib 2.N.1 releases
> >   that are older than ~12 months, and pick the
> >   highest N. That's our new GLIB_REQ then.
> >
> > The overall effect would be that when we release the next core/base the
> > required GLib version would be at least around 15-18 months old, which
> > seems fair to me (and what I think emerged as acceptable consensus the
> > last time we debated this issue on the mailing list).
> >
> > So:
> >
> >  - GLib 2.N.1 would be at least 12 months old
> >   *when we bump the requirement* (at this point
> >   only affecting GStreamer hackers)
> >
> >  - a core/base with this new requirement would
> >   be done ca. 3 months later, so at the time
> >   this new requirement hits GStreamer consumers
> >   and distributors the GLib version required
> >   would be at least 15 months old
> >
> >  - any GLib 2.N.x series will typically be
> >   maintained and in use for 6-9 months (random
> >   info on the side)
>
> I _would_ prefer to see the requirement change a little less
> frequently that this, though. Once a year, for example, rather than
> twice a year. To give a concrete suggestion then: I'd change your
> proposal to do this after every second core/base release.
>
> I'm not going to actively campaign against your plan if you think this
> is a bad idea, though.

A new GLib version every second core/base release sounds good to me and
this shouldn't be a too big problem for anybody IMHO. Most people will
have a newer GLib by that time anyway and all other should be able to
update GLib together with GStreamer...

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Bastien Nocera-2]

On Thu, 2009-02-19 at 10:17 -0800, Michael Smith wrote:
<snip>
> I _would_ prefer to see the requirement change a little less
> frequently that this, though. Once a year, for example, rather than
> twice a year. To give a concrete suggestion then: I'd change your
> proposal to do this after every second core/base release.
>
> I'm not going to actively campaign against your plan if you think this
> is a bad idea, though.

I guess whether or not the glib dep is updated really depends on whether
there are new features in the new version, or bug fixes that can't be
backported.

I don't think anyone would bump up the version reqs without any
forethought.


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Thomas Vander Stichele]

> 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.  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 ? Our user base is much
smaller there than on Linux.

You're assuming the problems can't be overcome, and it's about as valid
as them assuming your compatibility problems can't be overcome.


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 :)

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.

Upgrading the requirements for the sake of upgrading as a standard
practice sounds like the cart before the horse.

Thomas


--
And the awful weight
spread across me when I wake
is your loving arm around me
--
Flumotion - the only way to stream!
http://www.flumotion.net/



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Edward Hervey]

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.  Why is that user base small ? Because
> you make it hard for them to be big.

  That's pushing it a bit. (cross-)compiling glib is *really* trivial.
If that is one of the things stopping those user base getting bigger...
they're in for a ride.

  Let's put it another way. Distro X Enterprise (with their 3 aeons
support) doesn't update glib.
  Does it update anything else apart from critical security releases ?
No.
  Will DistroCompany update gstreamer (if it's available for starters) ?
No.
  Will it therefore update glib ? Maybe not... but that's not what's
stopping them from updating GStreamer.
  I think you're looking at the problem the other way round.

  We've been doing tarballs/rpms/debs for some people who were using
so-called enterprise distros to demo them gstreamer apps and it took...
what... a few hours maybe ? That's GStreamer + dependencies + plugins +
application.
  Did it require a rocket scientist ? No.
  Did it screw up their system ? No, because they were installed in a
non-/usr prefix, therefore our software was the only one using that.

>
> You're assuming the problems can't be overcome, and it's about as valid
> as them assuming your compatibility problems can't be overcome.
>
>
> 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 :)

  Is that a reason to stop us going forward ? Isn't it time we get them
fixed ? What if it gets fixes for a small-user-base
architecture/system ? Shouldn't they be able to use GStreamer too ?

  I don't want gstreamer to fix those issues just for GStreamer, I want
all glib-based libraries/applications to benefit from it (including
yours !).

  Edward


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

On Thu, 2009-02-19 at 10:17 -0800, Michael Smith wrote:

> I _would_ prefer to see the requirement change a little less
> frequently that this, though. Once a year, for example, rather than
> twice a year. To give a concrete suggestion then: I'd change your
> proposal to do this after every second core/base release.

I don't think it makes a difference whether we do this after every
release or every second release, so either works fine for me (I just
want to make use of new GLib features at some point without having to
persuade everyone and their dog each time that I really can't backport
the functionality or do without).

Cheers
 -Tim



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

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



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Ole Andre Vadla Ravnås]

On Thu, 2009-02-19 at 16:36 +0000, Tim-Philipp Müller wrote:
> Hi,
>
> I think we should try to bump our GLib requirements more often. Slowly
> and conservatively, but regularly.
(...)
> Thoughts? Sound good?

+1

Concerns regarding Enterprise distros have been raised, and IMHO if they
want to update GStreamer I can't see any reason why they cannot update
GLib too. After all it's ABI compatible, so they won't have to update
any other packages depending on GLib.

I'd say that the advantages of requiring a fairly recent version of GLib
by far outweigh the disadvantages. Think added maintenance burden
slowing down development, potential bugs and security issues in
duplicated code, noise from users hitting MT issues caused by outdated
GLib versions, etc.

Cheers,
Ole André

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Stefan Sauer]

Tim-Philipp Müller schrieb:

> Hi,
>
> I think we should try to bump our GLib requirements more often. Slowly
> and conservatively, but regularly.
>
> To this effect I propose some sort of informal GLib version policy,
> something like:
>
>  - whenever we release core/base, we look into
>    bumping the GLib requirement for core/base
>    (ie. right *after* the core/base release, not
>    for the release itself)
>
>  - we then look at all (stable) GLib 2.N.1 releases
>    that are older than ~12 months, and pick the
>    highest N. That's our new GLIB_REQ then.
>  

I like it. We miss all kind of new api already, e.g. g_sequence would be
nice to being able to use. I think a regular scheme has the benefit that
it takes place. Like doing regular releases. If there is a know problem
ith a new glib, then people will have issues with that one anyway,
regardless if we requeire it or not.

Stefan

> The overall effect would be that when we release the next core/base the
> required GLib version would be at least around 15-18 months old, which
> seems fair to me (and what I think emerged as acceptable consensus the
> last time we debated this issue on the mailing list).
>
> So:
>
>  - GLib 2.N.1 would be at least 12 months old
>    *when we bump the requirement* (at this point
>    only affecting GStreamer hackers)
>
>  - a core/base with this new requirement would
>    be done ca. 3 months later, so at the time
>    this new requirement hits GStreamer consumers
>    and distributors the GLib version required
>    would be at least 15 months old
>
>  - any GLib 2.N.x series will typically be
>    maintained and in use for 6-9 months (random
>    info on the side)
>
> Thoughts? Sound good?
>
> Cheers
>  -Tim
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>  

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel