On Sat, 2013-11-23 at 23:51 +0100, Dimstar / Dominique Leuenberger wrote:
On Sat, 2013-11-23 at 23:33 +0100, Raymond Wooninck wrote:
Hi listmates,
In the preparation of 13.1, Gnome came with the hard requirement to move up to the Gstreamer 1.0 version. For some time the indication was that only KDE was not support this "new" gstreamer version. At this moment KDE could offer a correct phonon-backend-gstreamer backend for gstreamer-1.0. In testing this branch it seems however that more programs are still actually using the old gstreamer-0_10.
The big ones top of my head are LibreOffice and Firefox. Smaller ones (but not less important) are wine, xfce (who already stated that they will never be able to port) and wxWidgets (and likely a lot things depending on it).
Another example is Bluez5, which now left KDE without proper bluetooth support, but it seems that Bluez5 itself is also not 100% working.
This had been discussed I don't know how often and KDE devs were committed in bringing this out in time. As of bluez5 not working 100 by itself: I'd been CCed on several bluez bugs, but haven't seen any pending. Please ensure that actual BLUEZ bugs are filed in bugzilla.
As already indicated by Dominique, GNome comes again with a new requirement, which is UPower 1.0. This one is not backwards compatible and a number of changes have to made in order to support this. Fortunately this time, KDE is ready for it but I wonder about all the other desktops that we are offering.
There is a 9 month upfront announcement and we already state that we won't be able to keep up the timelines to get this in? Ouch.
Based on above, I wonder what the goal is of GNome upstream as that it seems they are targeting to reach an incompatibility with all other desktops.
Yes, of course! What else? Honestly: GNOME relies on a bunch of 'external' libraries (like bluez, upower, libproxy, systemd, logind [...]). Some of them have actually contributions happening from GNOME as well, to ensure it interacts correctly. Seems KDE no longer is in the position to ensure this works for them as well? Maybe, instead of blaming some other group to 'remain on the ball', turn around and look what went wrong that KDE no longer can keep up?
For a lot of libs it's not uncommon in the GNOME area that there are wrapper libs provided...
My proposal would be to freeze the move of upower and first concentrate to get full gstreamer-1.0 support for all packages (Even our default browser (Mozilla, doesn;t support it) and full Bluez5 support for all before throwing in another variable.
gstreamer-0.10 does not 'stop' us from moving forward. it can co-exist. One thing which bluez could not do; and also upower won't be able to co-exist. Those are much larger targets to tackle and are more important to be done timely... things that can co-exist can, well, co-exist (with the obvious drawback that the old code will very likely not see fixes).
I agree - Given that gstreamer-0_10 can coexist with gstreamer-1.0, my suggestion would be for KDE to focus on those elements which cannot coexist, like bluez and upower I'm a little concerned that this appears to becoming a bit of reoccurring theme. It is my understanding that GNOME (both upstream and openSUSE) try to follow and make the most of upstream developments closely - this appears to be where the use of new gstreamer, upower, bluez, systemd, etc all come from. This approach seems to generally work well with the rest of our project at openSUSE, as we generally try to be a distribution that has the latest and greatest stable versions of everything in each release. KDE does not appear to have that same desire (or ability?) to progress at the same pace as the 'rest of the stack'. Is this a conscious decision by upstream KDE, or is a result of lack of resource? Is this something we need to, or can, address? I personally dislike the idea of slowing down the use of upstream developments if KDE cannot keep up, but at the same time we need to find a satisfactory way of providing a solid platform for our KDE users and as many new developments as their desktop choice can handle -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org