GStreamer 1.0 Is Looking To Finally Be Released Soon

[phoronix]

Phoronix: GStreamer 1.0 Is Looking To Finally Be Released Soon

Keynoting the GStreamer 2012 Conference in San Diego was Wim Taymans of Collabora. Taymans was talking about GStreamer 1.0, which should be officially released very soon -- perhaps before GNOME 3.6 ships...

http://www.phoronix.com/vr.php?view=MTE2OTQ

[oleid]

I don't see why the new gnome can't simply depend on at least gstreamer-0.11. Distributions can push the stable version, once it is released. Why rushing out a stable version, which isn't stable? The 1.0 stamp doesn't fix all the remaining bugs magically...

[Awesomeness]

I don't see why the new gnome can't simply depend on at least gstreamer-0.11. Distributions can push the stable version, once it is released. Why rushing out a stable version, which isn't stable? The 1.0 stamp doesn't fix all the remaining bugs magically...

And what difference would it make? Either it's a pre-release 0.11 version or a not-so-stable 1.0 version. GNOME 3.6 would depend on it anyway including all the bugs the users would encounter. It's not like not calling it 1.0 would make things better.

The real question is: Why did the GNOME devs once again rush to unstable dependencies?

[oleid]

And what difference would it make? Either it's a pre-release 0.11 version or a not-so-stable 1.0 version. GNOME 3.6 would depend on it anyway including all the bugs the users would encounter. It's not like not calling it 1.0 would make things better.

The difference is, that this makes version numbers meaningless (again), as seen e.g. with KDE 4.0. One should be able to trust, that a 1.0 is (more) stable (than a 0.11). Also calling it 0.11 might encourage distributions to backport a stable 1.0 once it is released.

The real question is: Why did the GNOME devs once again rush to unstable dependencies?

The things these bindings are needed for seem to be stable (or stable enough). Yet, your question is still a good one.

[GreatEmerald]

The difference is, that this makes version numbers meaningless (again), as seen e.g. with KDE 4.0. One should be able to trust, that a 1.0 is (more) stable (than a 0.11). Also calling it 0.11 might encourage distributions to backport a stable 1.0 once it is released.

Hence why I think SemVer/GemVer is a good idea. After all, +1.0 might mean that it's stable, or it might mean that it's a new development cycle.

[bkor]

The real question is: Why did the GNOME devs once again rush to unstable dependencies?

There was no rush. We made a concious decision to speed up the development of GStreamer 1.0 by porting applications to it. A library cannot become 1.0 without that happening. With applications being ported, you find problems in the API and because there are programs using the new library, people can discover bugs in them. Meaning: it becomes more stable.

When the decision was made, the schedule of Gstreamer 1.0 was supposed to match with GNOME 3.6. Obviously there is risk involved with such a large library. Something that is actually considered.

GNOME has been doing this with loads of libraries for the last 10 years or so, but as that all went ok I guess it was not noticed

[Awesomeness]

The difference is, that this makes version numbers meaningless (again), as seen e.g. with KDE 4.0.

Great you bring KDE 4.0 up, because not even KDE 4.0 relied on unstable 3rd party dependencies! KDE 4.0 was built on Qt 4.3 and not Qt 4.0 or even 4.0beta2 or whatever.

There was no rush. We made a concious decision to speed up the development of GStreamer 1.0 by porting applications to it. A library cannot become 1.0 without that happening. With applications being ported, you find problems in the API and because there are programs using the new library, people can discover bugs in them. Meaning: it becomes more stable.

When the decision was made, the schedule of Gstreamer 1.0 was supposed to match with GNOME 3.6. Obviously there is risk involved with such a large library. Something that is actually considered.

GNOME has been doing this with loads of libraries for the last 10 years or so, but as that all went ok I guess it was not noticed

Are you kidding me? Of course lots of people noticed when beta-quality dbus was introduced into GNOME, just as everybody noticed when Telepathy was added which couldn't even send files (= not feature-complete and therefore alpha quality), and the GNOME devs thought that replacing esd with PulseAudio was a great idea…
These are just the three top examples that I could come up with without even thinking.

This once again shows the beauty of KDE’s Phonon. Want to test GStreamer 1.0? Great, just fork the existing GStreamer 0.10 wrapper, modify and compile it against GStreamer 1.0 and all Phonon applications use GStreamer 1.0.

Why didn't you time GStreamer 1.0 to be ready for beta1 releases of GNOME? Then you'd have the entire beta period of GNOME to also fix GStreamer bugs and have a perfect point release ready for GNOME 3.x.0.

I wouldn't even bitch at all if the Gnomes didn't always shout how enterprise-ready they are and how unstable everything else supposedly is (usually pointing fingers to KDE).

[bkor]

Are you kidding me? Of course lots of people noticed when beta-quality dbus was introduced into GNOME, just as everybody noticed when Telepathy was added which couldn't even send files (= not feature-complete and therefore alpha quality), and the GNOME devs thought that replacing esd with PulseAudio was a great idea…

Lots of people? Citation needed.

All your other arguments are a bit.. strange.

E.g. not having a particular feature = alpha quality? That is not the definition of alpha quality.

PulseAudio bit is laughable as well. We made that optional for loads of various releases.

About dbus you don't really say anything.

These are just the three top examples that I could come up with without even thinking.

Suggest to bring better examples.

This once again shows the beauty of KDE’s Phonon. Want to test GStreamer 1.0? Great, just fork the existing GStreamer 0.10 wrapper, modify and compile it against GStreamer 1.0 and all Phonon applications use GStreamer 1.0.

Why didn't you time GStreamer 1.0 to be ready for beta1 releases of GNOME? Then you'd have the entire beta period of GNOME to also fix GStreamer bugs and have a perfect point release ready for GNOME 3.x.0.

I wouldn't even bitch at all if the Gnomes didn't always shout how enterprise-ready they are and how unstable everything else supposedly is (usually pointing fingers to KDE).

You seem to lack experience on how software is released.

[Awesomeness]

Lots of people? Citation needed.

I suggest you first back up your claim that nobody noticed similar development approaches for loads of other libraries over 10 years before you ask others to back up their claim.

E.g. not having a particular feature = alpha quality? That is not the definition of alpha quality.

Alpha versions: Not feature complete – new features get added from Alpha 1 to Alpha 2, for example.
Beta versions: Feature complete but buggy.
Release candidate: Feature complete and no known showstopper bugs.

That, at least, is the traditional categorization. I'm aware that there are competing approaches.

You seem to lack experience on how software is released.

Yes, I'm not active within GNOME to know how they release software.
I honestly do not understand several of GNOME’s release approaches: I do not understand how GNOME seems to rush to unstable dependencies (GNOME 3.0 required a beta version of NetworkManager 0.9, to name a 4th example, – a NM version KDE Network Management was incompatible with because, well, NM 0.8 was the stable one at that point. To make matters worse, the choice between NM 0.8 and 0.9 was exclusive, so installing GNOME 3.0 broke KDE Network Management and the GNOME devs didn't even care) as well as I do not understand why the GNOME devs think that only a single bugfix release is enough in each cycle (there is only GNOME 3.4.1, no 3.4.2 etc. – in contrast KDE released SC 4.8.5 recently). I do not understand why that single bugfix release is not even mentioned on http://www.gnome.org/news/.

So yeah, there is a whole lot I do not understand about GNOME but I doubt that GNOME's release process is pretty standard…

[bkor]

I suggest you first back up your claim that nobody noticed similar development approaches for loads of other libraries over 10 years before you ask others to back up their claim.

I think you need to re-read my statement. I said it went ok and I guess it was not noticed. I added a smiley. I could add a reference to what a smiley means, but I think that type of nitpicking is pointless.

Alpha versions: Not feature complete – new features get added from Alpha 1 to Alpha 2, for example.
Beta versions: Feature complete but buggy.
Release candidate: Feature complete and no known showstopper bugs.

That, at least, is the traditional categorization. I'm aware that there are competing approaches.

Feature complete as determined by the maintainer. I suggest you look up on time based releases. Or maybe look at KDE. A new KDE release adds some new feature. By your definition all previous KDE releases are buggy. Or a KDE release has a feature request in Bugzilla that is not fixed. In your definition, the new KDE release is alpha quality.

Yes, I'm not active within GNOME to know how they release software.
I honestly do not understand several of GNOME’s release approaches: I do not understand how GNOME seems to rush to unstable dependencies (GNOME 3.0 required a beta version of NetworkManager 0.9, to name a 4th example, – a NM version KDE Network Management was incompatible with because, well, NM 0.8 was the stable one at that point. To make matters worse, the choice between NM 0.8 and 0.9 was exclusive, so installing GNOME 3.0 broke KDE Network Management and the GNOME devs didn't even care) as well as I do not understand why the GNOME devs think that only a single bugfix release is enough in each cycle (there is only GNOME 3.4.1, no 3.4.2 etc. – in contrast KDE released SC 4.8.5 recently). I do not understand why that single bugfix release is not even mentioned on http://www.gnome.org/news/.

So yeah, there is a whole lot I do not understand about GNOME but I doubt that GNOME's release process is pretty standard…

What is your point? You like GNOME to take care of KDE? I thought we were talking about GStreamer. FWIW, individual modules do release updates... but I don't see how this has anything to do with GStreamer 1.0. It is a bit offtoptic, but do note that I took part in a KDE release team meeting @ Desktop Summit to 1) explain the GNOME take on things and 2) to share experiences with eachother.

The Phoronix article was about Gstreamer 1.0. I was talking about how we decided to help speed up development of GStreamer. You suggested adding a whole abstraction layer. For one something like that would probably take 2 years before it is fully stable. Additionally, this furthermore wouldn't allow testing of the GStreamer 1.0 API; just the bits similar to all the other video APIs. That is what I mean that you seem to lack experience... as this is just not workable.