Hello Wolfgang, thank you for raising your concerns. Please see my comments inline. On Thu, 2020-04-16 at 14:03 +0200, Wolfgang Rosenauer wrote:
Hi, please note that this reply is not directly related to the earlier posts but I didn't want to create another thread and I lost track and a few mails in my mailbox to find a better thread.
I was silently reading most of the mails but I'm still a bit confused and might not fully get it yet.
One thing of the discussion is not that important for me: If we use binary builds or source copies of packages imported from SLE. Yes, there are some challenges to do it right and keep it trustable and look into deeper details of build configurations so they are compatible. But this is just technology and I'm sure a bunch of people will work on that and cover it.
My main concern is though and it's not totally new:
Is Leap still an openSUSE project afterwards? Or is it SUSE controlled to an extent which does not qualify for the name openSUSE anymore?
Numbers say 8k+ packages managed by community 4k packages managed by SUSE with a help from community. At least 2/3 openSUSE, 1/3 SLE. I'd say mainly openSUSE :-) These 4k packages are addressed with a short-term vision of a transparent feature request for openSUSE Leap contributors (See my process-related comment bellow). Which I see as a step-up from situation.now().
We (or at least I) always understood that a hybrid distro like Leap will be some sort of compromise. In the 42.x series I was totally happy with the balance between openSUSE <-> SLE. With Leap 15 that was much stricter already. It became much more pain to request a fork or updates if the SLE version was not matching my expecations (as user and community maintainer of some packages). With the last 15.1 cycle it already was a major pain to get things in if a package was inherited from SLE. And now the whole thing seems as if it would be like totally prohibitive in many situations.
I unfortunately can't speak on behalf of the situation before openSUSE Leap 15.1/15.2. But I suppose you talk about Origin manager and waiving or rejecting changes based on the origin change. I also understand that some people were luckier than others on getting their requests. It could be because they were loud or features were greener than others, or perhaps people didn't know whom to reach out (See my process-related comment bellow).
Yes, I also want a solid base and I also like that SUSE does most of the maintenance work. But there were situations in the past years where for example I as the community maintainer failed to push an upgrade or a fork (I would maintain anyhow) into Leap when the package was based on SLE in the first place.
Similar concerns were raised by others in the previous posts and that's why I didn't write something up earlier but it seems the concerns were not taken serious enough.
I would have one prominent example about "mercurial". I guess most developers love to have more or less up to date version of their dev tools. This update request was rejected for obscure reasons (no they were not obscure, the reason was "we did not receive any business reasoning for the request"). The upgrade request was moved into an internal product and is now closed to the openSUSE community so I cannot refer to it. And that for a package I maintained for several years.
We're aware of this and we plan to address this by October 2020. SLE would like to treat openSUSE as a partner here. Process should be simple enough and offer fast-track for code-contributions. Where contributors would be able to see request updates, be able to comment, exchange patches and so on. SUSE has new tools in place, and I'd like to see them being used, and get external requests structure, expected visibility during evaluation. This was part of the announcement and is in https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap Until this is done I'd like to at least document the current situation and shed some light on it and improve where we can https://en.opensuse.org/Portal:Leap/SLEFeatureRequests
No, I don't have business reasons. I just want to have a (half-way) modern toolchain.
We all do. +Slightly better wireless device support in my case.
If it goes on like this and will be handled even stricter then I have to consider Leap a SUSE-only where the community is just a burden. Good enough to contribute to Factory and Tumbleweed but let your hands off "SUSE products" including Leap or "Jump".
I see previously mentioned partnership as a prerequisite for this hybrid distribution to function. Definitely not a burden. This is why the transparent feature req. process needs to take the place before the Jump proposal gets enrolled. The announcement indirectly mentions this (see my answers in the original announcement).
Wolfgang
-- Best regards Luboš Kocman Release Manager openSUSE Leap SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer