* Richard Brown
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.
Indeed, and not only for KDE.
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.
That has to do with the fact that there is considerable overlap and fluctuation between GNOME, Redhat and these projects which follow the CADT development model constantly changing APIs and often for no good reason at all (like the move from udisks 1 to 2, the polkit javascript debacle, the current upower changes, the removal of gstmixer etc.)
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.
It may work well for the openSUSE GNOME team because most the work is already done by a well-funded upstream project, but it certainly does not for all other desktops (be it KDE, Xfce, LXDE).
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?
I can only guess from myself or the Xfce community that it is not very motivating for unpaid volunteers to do porting work and chase constantly changing upstream projects which often has no immediate benefit.
Is this something we need to, or can, address?
Unless there is sufficient pain causing the development of an alternative middle stack, I'm not too optimistic.
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
I personally dislike the churn of the above upstream projects often breaking stuff for no good reason which in turn pins down resources in our project with porting and debugging work. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org