On Fri, 2020-04-10 at 10:57 +0300, Matwey V. Kornilov wrote:

09.04.2020 15:30, Adrian Schröter пишет:

...

On Donnerstag, 9. April 2020, 14:09:22 CEST wrote Stasiek Michalski: ..

...

The "pre-built binaries" and "SLE binaries" sound an awful lot like we will not have the full package build transparency we enjoy right now. Not particularly happy to hear that.

What do you mean with "build transparency" exactly?

The goal is definitive that the rebuild of any binary rpm should be repeatable. Yes, it would not have been build in build.opensuse.org, but it should have the same result (minus gpg signature) if doing so.

I agree that we need to verify that this is not just a goal, but indeed the case.

...

Leap did become "the better SLE" overtime, so we should have seen this coming a mile away, but I do not know how to feel about SLE basically using all of that work that the community did to achieve this. Maybe SUSE should just wait with those kinds of changes for when they feel comfortable with openly developing SLE instead, because that does bring in some value to both Leap and SLE and doesn't take away any of the things that the community added to Leap.

We understand that we also need to allow SLE submissions during this project.

We don't know how exactly to achieve this right now, I have to admit.

But we have this year to work on this...

IMO, SLE submissions have to be enabled before anything else, because it is already an issue. Many times when I had tried to make a maintenance update or update some package in upcoming Leap, I saw the same: "this package comes from SLE". And then it easily may take months to resolve the issue.

Hello Matwey, part of the proposal is also to allow contributors to file feature requests directly. Most of the issues are not implemented on time because they're tracked as a Leap bug, while in fact it's SLE RFE. Or there is no bz/feature tracker at all, just a rejected SR. I'm already trying to transition bugs containing such requests into SLE features for few weeks already. Most of them are either done or already approved and pending engineering work. My current experience that is we should be talking about 14 days if it's something reasonably small such as a minor version update or already comes with SR. The sooner in the development phase they'll be openned, the higher the change of getting changes into SLE. Hope it helps.

...

...

This does seem like a much more SLE focused than openSUSE Leap focused focused transition, branded as a positive change for openSUSE, but at least you did not excuse yourself with Coronavirus as did The Qt Company ;)

How do we figure out branding, how do we package things that actually have to differ between SLE and Jump? I do see the last question kind of skipping that point, does that mean the installation-images still will be different to account for different branding? Will the product package differ? Will the branding be figured out based on /etc/os-release?

Nah, branding is done with a different set of packages. openSUSE will definitive have it's own are of additional and also fork packages. The latter ones are the ones we try to minimize though.

...

What exact package-wise differences do you actually foresee. I don't agree with installation-time scriplets figuring this out though, since we have this amazing branding package system SUSE developed for UnitedLinux and openSUSE successfully used for plenty of years to not have to deal with terrible awful post script, please.

As an aside, Jump is an awful name, since it's a way too common of a word in the English language to build any reasonable branding around it. Please get Richard drunk enough so he can come up with something as good as Leap again.

actually I am guilty for Jump ... but I am happy with any other short name. I just need one for the initial setup. But we can change it later, if we come to a better conclusion here.

-- 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 N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�