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

On 11/25/2013 10:32 AM, Raymond Wooninck wrote:

On Monday 25 November 2013 15:56:28 Richard Brown wrote:

...

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

Who says that KDE is the issue here ? As I indicated in my original email, KDE will not have any problems with the switch to UPower. It already supports UPower 1.0.

My concern is however that other major components of openSUSE are either not seen as important or issues are just being resolved by creating compatibility packages to support the old libraries.

The mere reason behind my email was to create an awareness that openSUSE is not just KDE or GNOME, but has a lot of other desktops, packages, etc that should be supported. As is constantly indicated, a lot can be resolved by just keeping the old release and make it co-existent with the newer library. But did we ever validated this setup ? Yes, it might install, but does it provide an integrated desktop for the user ?

...

I'm a little concerned that this appears to becoming a bit of reoccurring theme.

Why wasn't this all then discussed in the past ?

...

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.

Yeah. Take FireFox as an example. Our standard webbrowser. Currently even the latest beta/unstable packages still rely heavily on Gstreamer 0.10. So I assume there goes your statement that this approach seems to generally work well.

...

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?

Again. It is not just KDE. Somehow you like to change this discussion to a KDE versus GNOME issue. Which is not the case. At least the last time I looked, Firefox, libreoffice, etc are not part of KDE.

...

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

Robert,

s/Robert/Richard/ Please don't blame me, I use XFCE ;)

I know that you are an 100% GNOME person, but again this is not a discussion regarding KDE versus GNOME. Maybe you like it to be as that you can then blame it on KDE.

On a more serious note, I doubt Richard wants to turn this into a KDE vs. GNOME issue, we are certainly past those times.

But just announcing that GNOME requires UPower 1.0 and that the rest simply have to follow, is in my opinion NOT the right approach regarding following upstream development. Did we ever consider Mate, Enlightenment, XFCE, etc ??

The fact that it was me who raised this issue, doesn't make it automatically a KDE issue.

The underlying question here is how do we handle upstream changes, that are only supported by a minority of the openSUSE packages. If the openSUSE community decides that we have to follow all upstream changes and really be on the latest available release of a library, package, etc, then so be it. However then they have to accept that this could mean that a big part of the openSUSE distribution might no longer work.

As an innocent bystander, i.e. not contributing to any DE development, I'd say breaking stuff is bad. If GNOME moves faster than others, due to the fact that they have a large paid contributor base upstream and appear generally to care less about ABI compatibility than they probably should, than, in a way it becomes a problem of the GNOME team in openSUSE to deal with this. Possibly more compatibility work has to be done. We have 5 DEs and all need to be considered IMHO, or our notion of "providing choice" somewhat becomes a hollow promise.

If the decision is however that in all cases everything shipped with openSUSE should work (with all features, etc), then we need to rethink the current way where a single desktop is pushing changes that are incompatible with the other desktops, applications.

Agreed, one would hope that there is a way to distribute the work and keep various versions of things at the same time. My $0.02 Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, On 11/25/2013 11:23 AM, Richard Brown wrote:

On Mon, 2013-11-25 at 16:32 +0100, Raymond Wooninck wrote:

...

Who says that KDE is the issue here ? As I indicated in my original email, KDE will not have any problems with the switch to UPower. It already supports UPower 1.0.

You did, when you brought up the example of Bluez5. As I'll explain below, the Gstreamer issue and Bluez issue are worlds apart, and as such I think they require different answers.

...

Yeah. Take FireFox as an example. Our standard webbrowser. Currently even the latest beta/unstable packages still rely heavily on Gstreamer 0.10. So I assume there goes your statement that this approach seems to generally work well.

When we're talking about libraries that are backwards compatible/able to coexist with their earlier versions, I see no problem with applications/packages/projects (delete as appropriate) using those older versions/API's

So, on the topic of Gstreamer, where we have the 0_10 packages which perfectly coexist with the 1.0 packages, I see no problem. Have both packages, if there's no conflict, there's no issue, and we can probably safely assume that those applications/packages/projects will eventually move to the 'new' versions in due course (as is the case with your example of Firefox)

...

The underlying question here is how do we handle upstream changes, that are only supported by a minority of the openSUSE packages. If the openSUSE community decides that we have to follow all upstream changes and really be on the latest available release of a library, package, etc, then so be it. However then they have to accept that this could mean that a big part of the openSUSE distribution might no longer work.

I think you're giving a false equivalence to all 'upstream changes'. The Gstreamer example is vastly different from the examples of upower & bluez

Gstreamer is an example of a non-issue - it's new packages dont break its old ones, so we can ship both, problem solved.

In the cases where new upstream versions don't have backwards compatibility/co-existance, the underlying question that remains is how do we handle the inclusion of those upstream developments that other packages/projects don't yet support.

My opinion is that if a project needs a stack provided by some mystical 'upstream', be it KDE, GNOME, XFCE, whatever, I think its down to that project to either keep up with their previously chosen 'upstream' provider, or find an alternative, or risk being seen as 'less relevant'

Lets stick with your example of BlueZ

In the case of bluez5, its been over a year since upstream bluez moved to version 5 which is incompatible with version 4.

For whatever reason, KDE in 13.1 was not able to support BlueZ5

This resulted in KDE shipping in openSUSE 13.1 without working Bluetooth. I think this is a perfectly acceptable (but not ideal) solution to the problem

It provides an incentive for upstream projects and openSUSE project maintainers to keep those projects moving forward and make the most of upstream developments.

What are the alternatives? Should we have delayed 13.1 so KDE can catch up? Should we have held back GNOME & upstream BlueZ? I think we chose the best solution for both openSUSE, upstream KDE, and other upstream projects - it signals a clear intention for projects to 'keep up' with the developments in the very components they, themselves, choose to rely on.

We're a project that normally embraces the idea of "Those who do, decide" - Upstream BlueZ did their changes, they decided to change their package, leaving us at openSUSE with a decision of our own - do we move with them, find something else, or do nothing and let our bluetooth stack break in the Desktop Environments that couldn't keep up?

I think we made the right call. Any egg on the face of KDE or other projects that couldn't keep up with BlueZ changes will hopefully encourage them to do better next time - and it's improvements like that which ultimately benefit everyone the most.

Ultimately, when projects repeatedly cant keep up with upstream changes, we can eventually end up with the question whether or not its sensible for us to continue to support that package/project.

Do we really want to support (at least to the same level as previously) a package that isn't keeping up with the changes its chosen upstream stacks are providing?

Maybe it shouldn't be part of the 'main' distro, on the DVD, which would actually alleviate our current workload having to do all the work to build/test/integrate/release the old project that cant keep up.

I don't think these questions are scary or should be avoided. We have finite resources, and cant support everything forever. Maybe this is a good way of deciding what parts of our distribution we keep and which components we part ways with.

I think you make a number of valid points. However I think the "cannot keep up" statement is a bit too far toward the "black and white" end of the spectrum. In the end the whole process tends more toward "eventual consistency", I think, and thus a big part of the discussion needs to be timing, IMHO. Just because one upstream project decides to work earlier with changes being implemented somewhere else than another upstream project doesn't necessarily imply that the later one does not or cannot keep up. Nor should this be used to "penalize" maintainers that care for upstream packages that might move a bit slower. As you point out it is a matter of choice and we have to decide how to deal with these things. I think in the end we probably cannot create some "general guideline" and will always be stuck with making these decisions on an individual basis. As a distribution we are trying to create a consistent set of "features/versions" on a given release cycle, ours, which by definition is an overlay of the release cycle of many upstream projects. This also implies, IMHO, that we have to be sympathetic for those maintainers that are supporting packages in openSUSE that may not have as vigorous or well funded upstream projects as others. Additionally, from my point of view, that would also imply that those in a position where upstream moves a bit faster than other upstreams, in adopting changes in shared functionality, should be approachable and be willing to help make things work in other areas. I am NOT implying that this is not the case, I think it is, just explicitly stating things. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 25.11.2013 17:23, schrieb Richard Brown:

Lets stick with your example of BlueZ

In the case of bluez5, its been over a year since upstream bluez moved to version 5 which is incompatible with version 4.

For whatever reason, KDE in 13.1 was not able to support BlueZ5

Well, it's not like bluez5 had been usable outside some specific embedded environments before bluez-5.6 or so. And GNOME did not have bluez5 support long before. I know because I regularly checked if *anybody* was using bluez5 already and if I could dare upating it for openSUSE and nobody did.

I think we made the right call. Any egg on the face of KDE or other projects that couldn't keep up with BlueZ changes will hopefully encourage them to do better next time - and it's improvements like that which ultimately benefit everyone the most.

for bluez that's probably correct, but breaking everything all the time just because we can and just because gnome is already able to use the latest stuff is not going to make people happy. They often would rather add their features and fix their own stuff instead of keeping up with the constant stream of breakage coming down from those upstream projects. Probably we'll need to start a desktop that keeps away from the freedesktop.org stuff ;-) -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Quoting Joachim Schrod :

PS: On technical terms, the issues of GNOME et.al. upstream playing loose with ABI breaks all the time have been mentioned often enough. Too bad they won't take any hint from the Linux developers, and recognize the importance of ABI stability. Any time, I read somebody threading the tone of Linus' emails on the kernel list about this topics, and how he should be more »professional« (read: more PC) -- I hope, that this won't happen and at least this basic part of our stack will retain its behavior to achieve really professional results.

Let's be fair, shall we? GStreamer is not a GNOME Project; it was discussed prior to inclusion and agreed the new versions will co-exist for a while Bluez is not a GNOME Project; it was discussed prior to inclusion and agreed on the drawbacks UPOwer is not a GNOME Project; it was discussed / announced well upfront. it's not even merged yet. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org