[opensuse-project] Bringing Leap and SUSE Linux Enterprise closer together - a proposal
Hi everyone, today I have some exciting news and a proposal to relay: SUSE wants to go another step in openness towards the openSUSE community and suggests to bring the relationship of openSUSE Leap and SUSE Linux Enterprise to a new level. Internally this idea is called "Closing the Leap Gap" and proposes to strengthen and bring more closely together: * developer communities, by focusing on openSUSE Leap as a development platform for communities and industry partners; * user communities, by leveraging the benefits of both a stable Enterprise code base and the speed of community contributions; * the code bases of openSUSE Leap and SUSE Linux Enterprise (SLE), by not only sharing sources, but also offering the SUSE Linux Enterprise binaries for inclusion in openSUSE Leap. The proposal includes a three step approach: 1. Merge the code bases for the intersection of openSUSE Leap 15.2 and SUSE Linux Enterprise 15 SP2 as much as possible without loss of functionality or stability. (SUSE has started a cleanup process on the SUSE Linux Enterprise side already.) 2. In parallel to classic openSUSE Leap 15.2 create a flavor leveraging SLE binaries, leading to an intermediate release in the October 2020 time frame. 3. Build openSUSE Leap 15.3 with SLE binaries included by default (assuming community agreement). As you can imagine, a number of people have been involved with this so far, and I'd like to pull some of them in front of the curtain in a little interview. Q: Thomas, all of engineering at SUSE reports to you, and I know openSUSE is something you care about quite a bit. What is SUSE putting on the table here? Thomas Di Giacomo: Let me step back, and give you a perspective as I see it. SUSE for 27+ years has been a part of global open source ecosystem that includes a vast number of developers, end users, communities, and organizations of all sizes working together and benefiting from the collective work. Most of our engineers are involved as well with some open source communities that they feel passionate about. Open source communities are an integral part of who we are and the ecosystem we serve. Naturally, we feel responsible to support the communities and the work done by them. openSUSE is no different and is actually even more special and very dear to SUSE. So, it should come as no surprise that we are fully committed towards the openSUSE project(s) and its community. It makes us all feel proud to see Leap and Tumbleweed grow and evolve, together with SUSE Linux Enterprise. This effort of our engineers working together with others in the openSUSE community will benefit everyone involved for many years to come. Q: And why are you doing this? Thomas: We want open source to succeed for everyone – developers, contributors to end users and everyone in between. The benefits of open source are tremendous when the ecosystem grows as a result of the positive virtuous cycle of – contributing more, supporting the contributions, benefiting from contributions, which inspires more people contributing, and it goes on to grow as an upward virtuous spiral. We feel fortunate to be in the position of seeing the openSUSE community grow in tandem with the success of SUSE Linux Enterprise, and both feeding off each other to grow even more. This idea definitely goes in that direction. Now, let me defer to Matthias who came up with this idea. Q: Okay, so, Matthias, first of all: what is your role at SUSE? Matthias Eckermann: I am leading the Product Management team for Linux platforms, covering SUSE Linux Enterprise, Edge, and Security. Q: And what made you propose this? Matthias: My team and I realized that the engagement of our SLE business with the openSUSE community does not fully fit our view on openness, and that mutual benefits are not leveraged sufficiently. We discussed what it would take to bridge the gap and bring the relationship to the next level. Beyond a common ground on the technical side, the code streams, this requires learning from each other; for example, we need to re-establish an open feature process between community, SUSE, and our industry partners. Thus we developed "Closing the Leap Gap", and - to test whether it might have a chance to fly - we outlined the initial idea with the openSUSE Board before going for approvals by SUSE management. Q: You mention the board, so let me ask. What is your take? What opportunities, benefits do you see? What risks? Dr. Axel Braun: With this change, we can make better use of our resources, as two code bases converge - so one build target less to consider. Everyone who packages for Leap and for Package Hub will immediately benefit from this. Marina Latini: It's really exciting to see how SUSE is trying to increase its support for Leap, reducing the existing differences between our openSUSE Leap and SLE. I can see this proposal as a way to be more inclusive, giving to the community the opportunity to contribute in an easier way to Leap and giving the chance to bring the openSUSE spirit also in an Enterprise product like SLE. On the other hand, every new move is a change and we need to be sure that the changes won't limit our community freedom to submit packages to Leap or won't slow down Leap for following the internal SUSE development model. Q: Matthias, that sounds like some extra effort required. How is SUSE contributing, what is SUSE committing to? Matthias: Indeed, there is quite some one-time effort needed to get (back) to the common ground; this is covered by SUSE engineering teams; two groups are heavily involved: The Open Build Service experts are designing a workflow for a smooth integration of the binaries, and for reducing the long term maintenance efforts for our community contributors. SUSE release managers and packagers are working hard to synchronize the code bases without losing functionality or quality. Hundreds of change requests have been filed already, and to get this done properly, we are delaying the release of SUSE Linux Enterprise 15 SP2 to July. And we are willing to invest more, to drive the idea to success quickly: we would take the burden, to create an intermediate openSUSE Leap release in October 2020 which then would incorporate SUSE Linux Enterprise binaries into Leap the first time. Probably, Adrian can comment on the Build Service aspects, and Lubos what it means to developers within SUSE and to the community release process? Q: So, Lubos, as release manager for Leap, what have you been doing so far, and what is the impact you see? Lubos Kocman: I spent most of the time on collecting data regarding SLE and Leap differences and having follow-up discussions and transforming feedback into action items. Max and the rest of the openSUSE release engineering team meanwhile did an excellent job of keeping Leap release activities going forward. The idea of re-using should generally lower the effort on the Leap side. However, it comes with the price of increased complexity to bring all pieces together. A new process will allow external contributors to file feature or update requests directly to SLE. This will already help a lot. Q: Is this an outcome bound effort, or time bound? I know the SLE release schedule is a bit like a 300m tanker. Lubos: It's both. I see this as a balance between what can we deliver, how, and to what date. It took quite some effort to create a plan acceptable by all involved teams. Splitting the work across the upcoming two releases seemed to be accepted well at least by involved parties so far. Q: So, that is SLE 15 SP2. How about Leap 15.2? Lubos: openSUSE Leap 15.2 will have to slip by about 8 weeks to incorporate all changes from the SLE and align with its new schedule. I believe that the release will find a great use for extra time since we're still finishing the refresh of packages from Factory. The prototype will be meanwhile available in parallel to the openSUSE Leap 15.2. Q: How is that research proceeding, Adrian? Adrian Schröter: We have an idea about the setup in build.opensuse.org. I anticipate to have a first prototype of the build setup in next three weeks. And more important is how to develop the workflows to allow a more collaborative joint effort between SLE and openSUSE development. However, we must keep in mind that this is really an entire new way to develop a distribution. On one hand it makes a lot of sense to integrate for example the SUSE Backports (aka Package Hub) people directly in our development process. This will make our distribution development stronger. On the other hand, we also must find ways how to solve new problems. For example how to keep our builds for architectures not covered by SLES like Arm 32bit and RISC-V. Also the turn around times of submissions and build results will be a challenge in the initial setup. And last but not least, the installed systems and users may need to deal with more repositories. But we have one year to work on these problems in parallel to our stable distribution. And we are indeed looking forward to make openSUSE and SLE development more beneficial than ever. Gerald: Thanks everyone for your input. I'll be sharing all this with openSUSE mailing lists, and am sure there will be further questions, offers to help, and other input, so please chime in there. https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap has an FAQ with more details. Lubos is going to send a proposal with more details on the implementation side to opensuse-factory@. I suggest we focus technical discussions of this offer and proposals there (opensuse-factory@) and general discussions on opensuse-project@. So, what do you think? Gerald -- Dr. Gerald Pfeifer <gp@suse.com>, CTO @SUSE + chair @openSUSE
On Thu, Apr 9, 2020 at 12:58, Gerald Pfeifer <gp@suse.com> wrote:
Hi everyone,
today I have some exciting news and a proposal to relay: SUSE wants to go another step in openness towards the openSUSE community and suggests to bring the relationship of openSUSE Leap and SUSE Linux Enterprise to a new level.
Internally this idea is called "Closing the Leap Gap" and proposes to strengthen and bring more closely together:
* developer communities, by focusing on openSUSE Leap as a development platform for communities and industry partners; * user communities, by leveraging the benefits of both a stable Enterprise code base and the speed of community contributions; * the code bases of openSUSE Leap and SUSE Linux Enterprise (SLE), by not only sharing sources, but also offering the SUSE Linux Enterprise binaries for inclusion in openSUSE Leap.
The proposal includes a three step approach:
1. Merge the code bases for the intersection of openSUSE Leap 15.2 and SUSE Linux Enterprise 15 SP2 as much as possible without loss of functionality or stability. (SUSE has started a cleanup process on the SUSE Linux Enterprise side already.) 2. In parallel to classic openSUSE Leap 15.2 create a flavor leveraging SLE binaries, leading to an intermediate release in the October 2020 time frame. 3. Build openSUSE Leap 15.3 with SLE binaries included by default (assuming community agreement).
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. 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. This does seem like a much more SLE focused than openSUSE Leap 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? 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. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
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...
This does seem like a much more SLE focused than openSUSE Leap 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. -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 4/9/20 10:00 PM, Adrian Schröter wrote:
On Donnerstag, 9. April 2020, 14:09:22 CEST wrote Stasiek Michalski:
This does seem like a much more SLE focused than openSUSE Leap 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.
To clarify this further branding is more general then just "branding" packages it will also include things like themes (kinda obvious) and patterns (less obvious). -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
I found this FAQ useful: https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap I need to read through all this again, maybe a couple times, to see what else is really changing. Package-compatibility is nice, but is the reason for that (vs. common sources) mostly for signed packages from SUSE available for both distros? I presume that's the goal, since otherwise we could just share sources, and in fact maybe we do/will, but sources do not lead to signed packages without private keys signing them once they are built. Aaron Burgemeister Identity / Security / Linux Consultant On Thu, Apr 9, 2020 at 6:36 AM Simon Lees <sflees@suse.de> wrote:
On 4/9/20 10:00 PM, Adrian Schröter wrote:
On Donnerstag, 9. April 2020, 14:09:22 CEST wrote Stasiek Michalski:
This does seem like a much more SLE focused than openSUSE Leap 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.
To clarify this further branding is more general then just "branding" packages it will also include things like themes (kinda obvious) and patterns (less obvious).
--
Simon Lees (Simotek) http://simotek.net
Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thu, 2020-04-09 at 06:40 -0600, Aaron Burgemeister wrote:
I found this FAQ useful: https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap
I need to read through all this again, maybe a couple times, to see what else is really changing. Package-compatibility is nice, but is the reason for that (vs. common sources) mostly for signed packages from SUSE available for both distros? I presume that's the goal, since otherwise we could just share sources, and in fact maybe we do/will, but sources do not lead to signed packages without private keys signing them once they are built.
That's correct re-using of SLE signed binaries for shared packages in Leap and SLE is a key part of the proposal.
Aaron Burgemeister Identity / Security / Linux Consultant
On Thu, Apr 9, 2020 at 6:36 AM Simon Lees <sflees@suse.de> wrote:
On 4/9/20 10:00 PM, Adrian Schröter wrote:
On Donnerstag, 9. April 2020, 14:09:22 CEST wrote Stasiek Michalski:
This does seem like a much more SLE focused than openSUSE Leap 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.
To clarify this further branding is more general then just "branding" packages it will also include things like themes (kinda obvious) and patterns (less obvious).
--
Simon Lees (Simotek) http://simotek.net
Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
-- 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
On 4/9/20 10:10 PM, Aaron Burgemeister wrote:
I found this FAQ useful: https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap
I need to read through all this again, maybe a couple times, to see what else is really changing. Package-compatibility is nice, but is the reason for that (vs. common sources) mostly for signed packages from SUSE available for both distros? I presume that's the goal, since otherwise we could just share sources, and in fact maybe we do/will, but sources do not lead to signed packages without private keys signing them once they are built.
One of the other things that it will allow is for Leap system's to be converted to SLE systems and the other way without needing to reinstall all the packages on the system because they now come from a different vendor. This could also potentially provide some interesting opportunities with things like cloud vendors in the future where maybe images are only available for one distro but not the other. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Thu, Apr 9, 2020 at 14:30, Adrian Schröter <adrian@suse.de> wrote:
On Donnerstag, 9. April 2020, 14:09:22 CEST wrote Stasiek Michalski:
This does seem like a much more SLE focused than openSUSE Leap 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.
I will drill this part, since it's the most interesting to me. If we shared 100% of binaries we would have SLE, not Jump in the repositories, so I assume we are gonna diverge somewhere. Which package will have a dependency on branding-openSUSE and distribution-logos-openSUSE-Leap (and if you want Jump if I get that branding going) so that branding is included in the installation images and the installed system. What statement in which package will decide which package to build for which repo. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Donnerstag, 9. April 2020, 15:14:50 CEST wrote Stasiek Michalski:
On Thu, Apr 9, 2020 at 14:30, Adrian Schröter <adrian@suse.de> wrote:
On Donnerstag, 9. April 2020, 14:09:22 CEST wrote Stasiek Michalski:
This does seem like a much more SLE focused than openSUSE Leap 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.
I will drill this part, since it's the most interesting to me. If we shared 100% of binaries we would have SLE, not Jump in the repositories, so I assume we are gonna diverge somewhere. Which package will have a dependency on branding-openSUSE and distribution-logos-openSUSE-Leap (and if you want Jump if I get that branding going) so that branding is included in the installation images and the installed system. What statement in which package will decide which package to build for which repo.
The product configuration is deciding which ones are to pick. And openSUSE "new Leap" (I call it Jump until there is a decision about the name) will have its own product configuration. And also own additional packages. So I see not really a difference to before here. -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thu, 2020-04-09 at 15:14 +0200, Stasiek Michalski wrote:
On Thu, Apr 9, 2020 at 14:30, Adrian Schröter <adrian@suse.de> wrote:
On Donnerstag, 9. April 2020, 14:09:22 CEST wrote Stasiek Michalski:
This does seem like a much more SLE focused than openSUSE Leap 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.
I will drill this part, since it's the most interesting to me. If we shared 100% of binaries we would have SLE, not Jump in the repositories, so I assume we are gonna diverge somewhere. Which package will have a dependency on branding-openSUSE and distribution-logos-openSUSE-Leap (and if you want Jump if I get that branding going) so that branding is included in the installation images and the installed system. What statement in which package will decide which package to build for which repo.
Hello Stasiek, I tried to touch this in Q. How will the difference between SLE and openSUSE be addressed? https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap Perhaps it's worth a page simlar to openSUSE Packaging Guidelines. Where we could elaborate and share some of the best practices.
LCP [Stasiek] https://lcp.world
-- 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
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.
This does seem like a much more SLE focused than openSUSE Leap 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.
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Hi On 4/10/20 5:27 PM, Matwey V. Kornilov wrote:
09.04.2020 15:30, Adrian Schröter пишет:
On Donnerstag, 9. April 2020, 14:09:22 CEST wrote Stasiek Michalski:
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.
If you feel like you are being held up in this area feel free to contact the board (or me). There are processes in place for this and when they work they work pretty well and efficiently, there are some places where its working really well. Unfortunately communication of these processes within SUSE hasn't always been fantastic so there are certain maintainers who are less aware of them, there are also sometimes where packages require new maintainers which can also take time. The SLE maintenance process is slightly more complex then the openSUSE one, due to the agreements SUSE has with its customers there are only certain things that we can normally process as a maintenance update (Leaps rules are much more flexible here), anything beyond that ends up needing management approval. Also unlike Leap all SLE maintenance updates go through a QA process, given the QA team has limited resources these updates are generally done in order of severity, so if there is a period where a larger number of security fixes need to go through then normal then sometimes other packages get held up. If you have a concern about a security related update then you can always contact the security team https://en.opensuse.org/openSUSE:Security_team So even with a more open development process which I hope we get at some point much of these processes will still need to stay the same and so the process will still likely take longer then the current leap process. Having said that some of the things listed in the first part of this email can be improved, but we can do that before moving to a shared development model. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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{.��k�7��맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.��k�7���0�����Ǩ�
reply to Stasiek Michalski:
[...]
3. Build openSUSE Leap 15.3 with SLE binaries included by default (assuming community agreement).
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.
Might be nice if it can be done the other way around: Those SUSE packagers can submit their SLE changes to openSUSE packages or start to maintain them, where no maintainer is in charge. The binaries build for openSUSE on obs can be used for SLE afterwards. What is the problem with this approach? The FAQ say: "Currently, this is not feasible due to several external factors, including certification requirements and technology partner handling." I have to admit to not understand this completely. It seems rather vague. Another (theoretical) question [not especially for Stasiek]: Imagine person A maintains package xy, submits to factory and it gets included in Leap. Now some (SUSE) person B starts to maintain xy for SLE. Someone (who?) decides xy is a "core" package and the SLE binaries should be used by Leap in the future. What happens to A? Does he still has a say on xy? If A wants to change something in xy for Leap, does he has to ask B (via a SLE feature request) first? If yes, this seems like community maintainers have to do more work while having less "power" compared to their SLE colleagues. Doesn't this introduce the potential of conflicts (between A and B)? What B calls a mistake, A might consider to be a feature. If B has by default the last say, we might loose community maintainers, at least for "core" packages. So, additionally to "Factory first", "Leap second" and "SLE third" might be an idea. [...]
Please get Richard drunk enough so he can come up with something as good as Leap again.
Tend to remember someone called Rainer (or similar) came up with "Leap". [...] cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Hi, On 4/10/20 1:39 PM, cunix wrote:
reply to Stasiek Michalski:
[...]
3. Build openSUSE Leap 15.3 with SLE binaries included by default (assuming community agreement).
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.
Might be nice if it can be done the other way around:
Those SUSE packagers can submit their SLE changes to openSUSE packages or start to maintain them, where no maintainer is in charge.
The binaries build for openSUSE on obs can be used for SLE afterwards.
What is the problem with this approach?
Security certifications. In order to make security certifications for SLE possible the binaries have to be built in the SUSE controlled instance of the build service. thus copying of binaries from the openSUSE Build Service to the SUSE internal build service is not an option.
The FAQ say: "Currently, this is not feasible due to several external factors, including certification requirements and technology partner handling."
I have to admit to not understand this completely. It seems rather vague.
The partner aspect is that we work on features that are under NDA, thus cannot be developed in OBS, until partners make announcements. But we still have to have packages that have these features. Therefore submissions happen in the SUSE internal build service so we have packages for testing. Once the partner announces the features the packages go to the SLE repos and migrate to OBS.
Another (theoretical) question [not especially for Stasiek]:
Imagine person A maintains package xy, submits to factory and it gets included in Leap.
Now some (SUSE) person B starts to maintain xy for SLE.
Someone (who?) decides xy is a "core"
The use of "core" is a bit overloaded and in this case can lead to misunderstanding. The goal is every package that is in SLE and overlaps with Leap is imported in this way.
package and the SLE binaries should be used by Leap in the future.
What happens to A? Does he still has a say on xy?
Yes, absolutely. The SUSE maintainer becomes a co-maintainer just as if another person that doesn't happen to work for SUSE could be a co-maintainer.
If A wants to change something in xy for Leap, does he has to ask B (via a SLE feature request) first?
Well if A wants to make a change that change should go through a review process via SR such that interested parties can discuss the changes. Nothing should change here since the SR process is/should be common practice. When there is more than 1 maintainer of a package the none of the maintainers should just make changes without having another set of eyes on the changes.
If yes, this seems like community maintainers have to do more work while having less "power" compared to their SLE colleagues.
Doesn't this introduce the potential of conflicts (between A and B)?
This potential is no larger than it is today, for every package that has at least 2 maintainers. Granted for many packages we have no maintainers and devel project maintainers become the stewards of those packages. For many packages there exists only 1 maintainer and if that package becomes part of SLE than yes that 1 maintainer will get company. But two heads generally produce better results then 1, so that should be an advantage.
What B calls a mistake, A might consider to be a feature.
If B has by default the last say, we might loose community maintainers, at least for "core" packages.
There is still a hurdle, and that has been acknowledged, in that SLE processes are a stick in the mud and changes on that end are necessary. How this works out will be seen as jump gets implemented and develops. There is certainly the possibility that SLE processes continue to be a PITA and the model is not workable. But we'll never know if we don't try. Maintainers that do not happen to work for SUSE should certainly NOT be considered as "junior" and in openSUSE have equal say to a maintainer that happens to work for SUSE. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
reply to Robert Schweikert:
Hi,
Thanks for the answer Robert! [...]
What is the problem with this approach?
Security certifications.
In order to make security certifications for SLE possible the binaries have to be built in the SUSE controlled instance of the build service. thus copying of binaries from the openSUSE Build Service to the SUSE internal build service is not an option.
That is easier to understand. If openSUSE users should use binaries from a build instance they can't control or look into, there really needs to be a way they can trust it the same way as obs - Adrian Schroeter already said so previously. Otherwise various package "forks" on obs may arise. What is the problem with rebuilding the SLE binaries on obs for openSUSE? Saving build power? [...]
The partner aspect is that we work on features that are under NDA, thus cannot be developed in OBS, until partners make announcements. But we still have to have packages that have these features. Therefore submissions happen in the SUSE internal build service so we have packages for testing. Once the partner announces the features the packages go to the SLE repos and migrate to OBS.
In my example with the openSUSE co-maintainers A and B for package xy, B (she is additionally the SLE maintainer) will probably be the one who prepares the package in the SUSE build service and make it "obs ready" but she is not allowed to talk to A until obs migration. What happens if A (only openSUSE maintainer) has (technical) reasons to prefer another solution? Isn't it likely that B has only little room to compromise at this point in time and won't A find himself in a weaker position because of less/later knowledge? Consequently, to not risk such conflicts, wouldn't B (or her manager) prefer to have B as the only maintainer in charge? Of course I don't know how often such situation may occur. [...]
If A wants to change something in xy for Leap, does he has to ask B (via a SLE feature request) first?
Well if A wants to make a change that change should go through a review process via SR such that interested parties can discuss the changes.Nothing should change here since the SR process is/should be common practice.
Aha. My first understanding was, the (openSUSE) maintainers shouldn't submit their changes directly to Leap anymore, but have to first convince (by SR or feature request) the SLE maintainer to accept the change/update for SLE and than this guy has to push the new SLE package version to Leap.
When there is more than 1 maintainer of a package the none of the maintainers should just make changes without having another set of eyes on the changes.
Agree. [...]
Doesn't this introduce the potential of conflicts (between A and B)?
This potential is no larger than it is today, for every package that has at least 2 maintainers.
O.K. Probably I don't have enough experience here. While it is most of the time really beneficial to have multiple maintainers, my fear was that disagreement is more likely if one maintainer is openSUSE only while the other's main focus is SLE. In case of conflict the later may argue only her proposal is acceptable for SLE and if the former does not accept, she will go forward and change (her) SLE package and submit this version to Leap. [...]
know if we don't try. Maintainers that do not happen to work for SUSE should certainly NOT be considered as "junior" and in openSUSE have equal say to a maintainer that happens to work for SUSE.
That is good to hear.
Later, Robert
Thank you very much, cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 4/11/20 9:20 AM, cunix wrote:
If openSUSE users should use binaries from a build instance they can't control or look into, there really needs to be a way they can trust it the same way as obs - Adrian Schroeter already said so previously. Otherwise various package "forks" on obs may arise.
What is the problem with rebuilding the SLE binaries on obs for openSUSE? Saving build power?
Packages built on openSUSE's build server are signed with openSUSE certificates where as packages built on SUSE's build server are signed with SUSE certificates which would mean the packages would still be different. Another thing SUSE is considering here is there has already been significant work toward making a significant percentage of packages build reproducably and one thing SUSE is considering is to make sure all there packages build reproducably so that the community can verify this. All of the packages should still be exported into obs as sources which would again make this process easier.
The partner aspect is that we work on features that are under NDA, thus cannot be developed in OBS, until partners make announcements. But we still have to have packages that have these features. Therefore submissions happen in the SUSE internal build service so we have packages for testing. Once the partner announces the features the packages go to the SLE repos and migrate to OBS.
In my example with the openSUSE co-maintainers A and B for package xy, B (she is additionally the SLE maintainer) will probably be the one who prepares the package in the SUSE build service and make it "obs ready" but she is not allowed to talk to A until obs migration.
What happens if A (only openSUSE maintainer) has (technical) reasons to prefer another solution?
Isn't it likely that B has only little room to compromise at this point in time and won't A find himself in a weaker position because of less/later knowledge?
Consequently, to not risk such conflicts, wouldn't B (or her manager) prefer to have B as the only maintainer in charge?
This would be seen as a conflict between two maintainers and could be escalated to the openSUSE Board who would then work to resolve the conflict as per openSUSE's conflict resolution process. (This is one of the board's key roles).
[...]
If A wants to change something in xy for Leap, does he has to ask B (via a SLE feature request) first?
Well if A wants to make a change that change should go through a review process via SR such that interested parties can discuss the changes.Nothing should change here since the SR process is/should be common practice.
Aha. My first understanding was, the (openSUSE) maintainers shouldn't submit their changes directly to Leap anymore, but have to first convince (by SR or feature request) the SLE maintainer to accept the change/update for SLE and than this guy has to push the new SLE package version to Leap.
Your understanding is correct, changes going into SLE need to be agreed to by the SLE maintainer. If you can make a copy of the proposed changes in your home directory it generally makes it much easier for the SLE maintainer to review and incorporate. If you can't contact the maintainer then creating a SR against leap is fine and the release managers will hopefully be able to follow it up.
When there is more than 1 maintainer of a package the none of the maintainers should just make changes without having another set of eyes on the changes.
Agree.
[...]
Doesn't this introduce the potential of conflicts (between A and B)?
This potential is no larger than it is today, for every package that has at least 2 maintainers.
O.K. Probably I don't have enough experience here.
While it is most of the time really beneficial to have multiple maintainers, my fear was that disagreement is more likely if one maintainer is openSUSE only while the other's main focus is SLE.
In case of conflict the later may argue only her proposal is acceptable for SLE and if the former does not accept, she will go forward and change (her) SLE package and submit this version to Leap.
Again see above, although SUSE maintainers do have to follow SUSE's rules for what submissions can be made as part of the SLE maintenance process for updates. In some very certain cases if there are reasons why the change can't go into SLE but the change is very beneficial to openSUSE users we will still have the ability to ship a different package for openSUSE with those changes but we are trying really hard to avoid that. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
reply to Simon Lees:
On 4/11/20 9:20 AM, cunix wrote:
Thanks for the answer, Simon! [...]
Isn't it likely that B has only little room to compromise at this point in time and won't A find himself in a weaker position because of less/later knowledge?
Consequently, to not risk such conflicts, wouldn't B (or her manager) prefer to have B as the only maintainer in charge?
This would be seen as a conflict between two maintainers and could be escalated to the openSUSE Board who would then work to resolve the conflict as per openSUSE's conflict resolution process. (This is one of the board's key roles).
Yes, but my argument was: To not get into a situation, where conflict resolution by board might be needed, there might be an incentive for B (or her manager) to not accept someone (A) from the community as co-maintainer in the first place. If A was already maintainer when B joins because she is the SLE maintainer, she might have an interest in A stepping down to not risk disagreement in the future. [...]
Well if A wants to make a change that change should go through a review process via SR such that interested parties can discuss the changes.Nothing should change here since the SR process is/should be common practice.
Aha. My first understanding was, the (openSUSE) maintainers shouldn't submit their changes directly to Leap anymore, but have to first convince (by SR or feature request) the SLE maintainer to accept the change/update for SLE and than this guy has to push the new SLE package version to Leap.
Your understanding is correct, changes going into SLE need to be agreed to by the SLE maintainer. If you can make a copy of the proposed changes in your home directory it generally makes it much easier for the SLE maintainer to review and incorporate.
Then my doubts still apply because there might be an unbalance of power between co-maintainers where one is community only while the other is additionally the SLE maintainer. Doesn't the later have a "double" vote in discussions with her co-maintainer, because she can additionally "veto" any decision by declining the SR to SLE? Does conflict resolution by board help here, because I don't expect the openSUSE board to have "official" influence on SLE maintainers? [...]
Again see above, although SUSE maintainers do have to follow SUSE's rules for what submissions can be made as part of the SLE maintenance process for updates. In some very certain cases if there are reasons why the change can't go into SLE but the change is very beneficial to openSUSE users we will still have the ability to ship a different package for openSUSE with those changes but we are trying really hard to avoid that.
Hopefully this will work out in practice. My fear was, (SLE) B has more interest in keeping package versions in SLE and Leap at the same level, while (community) maintainer A might want to get closer to the Factory version. To not have to discuss this issue further, both might strive to become the only maintainer. cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Samstag, 11. April 2020, 19:48:46 CEST wrote cunix:
reply to Simon Lees:
On 4/11/20 9:20 AM, cunix wrote:
Thanks for the answer, Simon!
[...]
Isn't it likely that B has only little room to compromise at this point in time and won't A find himself in a weaker position because of less/later knowledge?
Consequently, to not risk such conflicts, wouldn't B (or her manager) prefer to have B as the only maintainer in charge?
This would be seen as a conflict between two maintainers and could be escalated to the openSUSE Board who would then work to resolve the conflict as per openSUSE's conflict resolution process. (This is one of the board's key roles).
Yes, but my argument was: To not get into a situation, where conflict resolution by board might be needed, there might be an incentive for B (or her manager) to not accept someone (A) from the community as co-maintainer in the first place.
If A was already maintainer when B joins because she is the SLE maintainer, she might have an interest in A stepping down to not risk disagreement in the future.
I understand your concerns here, but I see no difference between Leap and Jump concept here. IMHO we should seperate this discussion therefore from the Jump concept discussion. And keep in mind we keep the option to fork packages from SLE in openSUSE. It is just a declared goal to minimize these packages.
Well if A wants to make a change that change should go through a review process via SR such that interested parties can discuss the changes.Nothing should change here since the SR process is/should be common practice.
Aha. My first understanding was, the (openSUSE) maintainers shouldn't submit their changes directly to Leap anymore, but have to first convince (by SR or feature request) the SLE maintainer to accept the change/update for SLE and than this guy has to push the new SLE package version to Leap.
Your understanding is correct, changes going into SLE need to be agreed to by the SLE maintainer. If you can make a copy of the proposed changes in your home directory it generally makes it much easier for the SLE maintainer to review and incorporate.
Then my doubts still apply because there might be an unbalance of power between co-maintainers where one is community only while the other is additionally the SLE maintainer.
Doesn't the later have a "double" vote in discussions with her co-maintainer, because she can additionally "veto" any decision by declining the SR to SLE?
Does conflict resolution by board help here, because I don't expect the openSUSE board to have "official" influence on SLE maintainers?
IMHO the board is no technical steering commitee. At least it was it was not elected as such. Maybe we should have one though ... But so far these decisions (and also to fork or not fork a package for openSUSE) is done by the release manager (Lubos) in this case. happy easter! adrian -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
reply to Adrian Schröter:
On Samstag, 11. April 2020, 19:48:46 CEST wrote cunix:
reply to Simon Lees:
On 4/11/20 9:20 AM, cunix wrote:
Thanks for the answer Adrian! [...]
Yes, but my argument was: To not get into a situation, where conflict resolution by board might be needed, there might be an incentive for B (or her manager) to not accept someone (A) from the community as co-maintainer in the first place.
If A was already maintainer when B joins because she is the SLE maintainer, she might have an interest in A stepping down to not risk disagreement in the future.
I understand your concerns here, but I see no difference between Leap and Jump concept here. IMHO we should seperate this discussion therefore from the Jump concept discussion.
O.K. The difference is in my opinion: The more packages are shared between SLE and Leap, the more likely such a situation might evolve, where a conflict might occur or is prevented beforehand by reducing shared maintenance done by people coming from different backgrounds. As I understand Jump, its goal is to increase the number of packages shared.
And keep in mind we keep the option to fork packages from SLE in openSUSE. It is just a declared goal to minimize these packages.
Although the option is there, me feared the desire of community co-maintainers to introduce a feature update of a package in Leap becomes harder to realize, if it is not wanted by policy, the (SLE) co-maintainers have to be convinced - who has an interest in keeping version of SLE and Leap in sync - and they have now to jump more often over the "fork" hurdle. [...]
happy easter! adrian
Happy Easter, cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Hi, On 4/12/20 11:39 AM, cunix wrote:
reply to Adrian Schröter:
On Samstag, 11. April 2020, 19:48:46 CEST wrote cunix:
reply to Simon Lees:
On 4/11/20 9:20 AM, cunix wrote:
Thanks for the answer Adrian!
[...]
Yes, but my argument was: To not get into a situation, where conflict resolution by board might be needed, there might be an incentive for B (or her manager) to not accept someone (A) from the community as co-maintainer in the first place.
If A was already maintainer when B joins because she is the SLE maintainer, she might have an interest in A stepping down to not risk disagreement in the future.
I understand your concerns here, but I see no difference between Leap and Jump concept here. IMHO we should seperate this discussion therefore from the Jump concept discussion.
O.K. The difference is in my opinion: The more packages are shared between SLE and Leap, the more likely such a situation might evolve, where a conflict might occur or is prevented beforehand by reducing shared maintenance done by people coming from different backgrounds. As I understand Jump, its goal is to increase the number of packages shared.
And keep in mind we keep the option to fork packages from SLE in openSUSE. It is just a declared goal to minimize these packages.
Although the option is there, me feared the desire of community co-maintainers to introduce a feature update of a package in Leap becomes harder to realize, if it is not wanted by policy, the (SLE) co-maintainers have to be convinced - who has an interest in keeping version of SLE and Leap in sync - and they have now to jump more often over the "fork" hurdle.
I can only speak for the Public Cloud team, we'd love to have more co-maintainers for packages we maintain. I understand your concern but I do not think there is a general statement that can be made. It is going to be very dependent on the package, where in SLES it is released, for example glibc and such things are harder to change than a package that is part of the Public Cloud module. Again, we have to see how it works out. Having lots of theoretical constructs is not necessarily going to help us. There are so many factors that come into play, personality of the co-maintainers, where the package is released in SLES and others. Certainly there will be hiccups and we'll have to cross that bridge when we get there. A long time ago we created [1] which outlines some of the concerns you are raising. As far as I am concerned this is till perfectly valid and we have mechanisms in place to handle various situations. Later, Robert [1] https://en.opensuse.org/openSUSE:Freight_Train -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
On 13.04.20 at 21:28 Robert Schweikert wrote:
Again, we have to see how it works out. Having lots of theoretical constructs is not necessarily going to help us. There are so many factors that come into play, personality of the co-maintainers, where the package is released in SLES and others. Certainly there will be hiccups and we'll have to cross that bridge when we get there. A long time ago we created [1] which outlines some of the concerns you are raising. As far as I am concerned this is till perfectly valid and we have mechanisms in place to handle various situations.
Well spoken. Let's solve the problems once they really exist... Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
reply to Robert Schweikert:
Hi,
Hi, [...]
I can only speak for the Public Cloud team, we'd love to have more co-maintainers for packages we maintain.
I understand your concern but I do not think there is a general statement that can be made. It is going to be very dependent on the package, where in SLES it is released, for example glibc and such things are harder to change than a package that is part of the Public Cloud module.
Again, we have to see how it works out. Having lots of theoretical constructs is not necessarily going to help us. There are so many factors that come into play, personality of the co-maintainers, where the package is released in SLES and others. Certainly there will be hiccups and we'll have to cross that bridge when we get there. A long time ago we created [1] which outlines some of the concerns you are raising. As far as I am concerned this is till perfectly valid and we have mechanisms in place to handle various situations.
All right. And thank you for the link - I didn't saw it before.
Later, Robert
[1] https://en.opensuse.org/openSUSE:Freight_Train cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Sat, 2020-04-11 at 19:48 +0200, cunix wrote:
reply to Simon Lees:
On 4/11/20 9:20 AM, cunix wrote:
Thanks for the answer, Simon!
[...]
Isn't it likely that B has only little room to compromise at this point in time and won't A find himself in a weaker position because of less/later knowledge?
Consequently, to not risk such conflicts, wouldn't B (or her manager) prefer to have B as the only maintainer in charge?
This would be seen as a conflict between two maintainers and could be escalated to the openSUSE Board who would then work to resolve the conflict as per openSUSE's conflict resolution process. (This is one of the board's key roles).
Yes, but my argument was: To not get into a situation, where conflict resolution by board might be needed, there might be an incentive for B (or her manager) to not accept someone (A) from the community as co-maintainer in the first place.
If A was already maintainer when B joins because she is the SLE maintainer, she might have an interest in A stepping down to not risk disagreement in the future.
[...]
Well if A wants to make a change that change should go through a review process via SR such that interested parties can discuss the changes.Nothing should change here since the SR process is/should be common practice.
Aha. My first understanding was, the (openSUSE) maintainers shouldn't submit their changes directly to Leap anymore, but have to first convince (by SR or feature request) the SLE maintainer to accept the change/update for SLE and than this guy has to push the new SLE package version to Leap.
Your understanding is correct, changes going into SLE need to be agreed to by the SLE maintainer. If you can make a copy of the proposed changes in your home directory it generally makes it much easier for the SLE maintainer to review and incorporate.
Then my doubts still apply because there might be an unbalance of power between co-maintainers where one is community only while the other is additionally the SLE maintainer.
Fortunately this is not my recent experience with Leap feature request mainly to udpate packages. All of them were approved. One had to be deferred to the next relase as it would require rebuild of lot of packages in SP2:GA and inherited :Update streams.
Doesn't the later have a "double" vote in discussions with her co-maintainer, because she can additionally "veto" any decision by declining the SR to SLE?
Does conflict resolution by board help here, because I don't expect the openSUSE board to have "official" influence on SLE maintainers?
[...]
Again see above, although SUSE maintainers do have to follow SUSE's rules for what submissions can be made as part of the SLE maintenance process for updates. In some very certain cases if there are reasons why the change can't go into SLE but the change is very beneficial to openSUSE users we will still have the ability to ship a different package for openSUSE with those changes but we are trying really hard to avoid that.
Hopefully this will work out in practice. My fear was, (SLE) B has more interest in keeping package versions in SLE and Leap at the same level, while (community) maintainer A might want to get closer to the Factory version.
To not have to discuss this issue further, both might strive to become the only maintainer.
cunix
-- 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{.��k�7��맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.��k�7���0�����Ǩ�
reply to Lubos Kocman:
On Sat, 2020-04-11 at 19:48 +0200, cunix wrote:
On 4/11/20 9:20 AM, cunix wrote: [...] Then my doubts still apply because there might be an unbalance of
reply to Simon Lees: power between co-maintainers where one is community only while the other is additionally the SLE maintainer.
Fortunately this is not my recent experience with Leap feature request mainly to udpate packages. All of them were approved. One had to be deferred to the next relase as it would require rebuild of lot of packages in SP2:GA and inherited :Update streams.
I do acknowledge that you have much more insight. Me didn't want to say what happens currently or what has happened in the past, but only want to raise awareness to what might be more likely to happen in a future where the number of packages shared by SLE and Leap increase. [...] cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 4/11/20 5:41 AM, Simon Lees wrote:
On 4/11/20 9:20 AM, cunix wrote:
If openSUSE users should use binaries from a build instance they can't control or look into, there really needs to be a way they can trust it the same way as obs - Adrian Schroeter already said so previously. Otherwise various package "forks" on obs may arise.
What is the problem with rebuilding the SLE binaries on obs for openSUSE? Saving build power?
Packages built on openSUSE's build server are signed with openSUSE certificates where as packages built on SUSE's build server are signed with SUSE certificates which would mean the packages would still be different.
And this is a very important consideration from a support perspective. One part of this is that a user can switch from openSUSE to SLES without having to re-install/switch a bunch of packages. Example: If a user sets up a server using openSUSE Leap and uses only packages that are in the overlapping set between Leap and SLES that user can have a business action only switch from Leap to SLES. Since the packages are already signed by the SUSE key everything in the support system just works once the user is enabled on the business end. That doesn't work for all cases of course. When a user has a system that use KDE and wants support then the user cannot get support for KDE as SLES + Workstation Extension or SLED support GNOME. However, since KDE is in PackageHub the user can still get support for all the packages signed by the SUSE key. Hope this helps in illustrating the advantages for the user w.r.t. using one signing key vs. the other. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
reply to Robert Schweikert:
On 4/11/20 5:41 AM, Simon Lees wrote:
On 4/11/20 9:20 AM, cunix wrote:
If openSUSE users should use binaries from a build instance they can't control or look into, there really needs to be a way they can trust it the same way as obs - Adrian Schroeter already said so previously. Otherwise various package "forks" on obs may arise.
What is the problem with rebuilding the SLE binaries on obs for openSUSE? Saving build power?
Packages built on openSUSE's build server are signed with openSUSE certificates where as packages built on SUSE's build server are signed with SUSE certificates which would mean the packages would still be different.
And this is a very important consideration from a support perspective. One part of this is that a user can switch from openSUSE to SLES without having to re-install/switch a bunch of packages.
Example:
If a user sets up a server using openSUSE Leap and uses only packages that are in the overlapping set between Leap and SLES that user can have a business action only switch from Leap to SLES. Since the packages are already signed by the SUSE key everything in the support system just works once the user is enabled on the business end.
That doesn't work for all cases of course. When a user has a system that use KDE and wants support then the user cannot get support for KDE as SLES + Workstation Extension or SLED support GNOME. However, since KDE is in PackageHub the user can still get support for all the packages signed by the SUSE key.
Hope this helps in illustrating the advantages for the user w.r.t. using one signing key vs. the other.
I do see the benefit this will bring for some folks but hope to limit the consequences for others. Are some numbers available how often Leap to SLE switches happen compared to the number of all Leap user installs? And perhaps how often complains are raised because of the need to reinstall packages? Please let me exaggerate a little bit: Are we trading saving bandwidth for those wanting to switch at the price of requiring all Leap users to add and trust a signing key of an entity that might follow rules not controlled by openSUSE? I don't want to argue against having SUSE signed binaries in the openSUSE repositories but would really prefer if a technical solution can be found, where this is not the only signature. With such multi-signed packages Leap users can solely rely on the openSUSE signature, while those switching to SLE (what has to include adding trust to the SUSE key) have SUSE signatures already available for shared packages without need to reinstall.
Later, Robert
cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tue, Apr 14, 2020 at 10:20 AM cunix <cunix@gmx.net> wrote:
reply to Robert Schweikert:
On 4/11/20 5:41 AM, Simon Lees wrote:
On 4/11/20 9:20 AM, cunix wrote:
If openSUSE users should use binaries from a build instance they can't control or look into, there really needs to be a way they can trust it the same way as obs - Adrian Schroeter already said so previously. Otherwise various package "forks" on obs may arise.
What is the problem with rebuilding the SLE binaries on obs for openSUSE? Saving build power?
Packages built on openSUSE's build server are signed with openSUSE certificates where as packages built on SUSE's build server are signed with SUSE certificates which would mean the packages would still be different.
And this is a very important consideration from a support perspective. One part of this is that a user can switch from openSUSE to SLES without having to re-install/switch a bunch of packages.
Example:
If a user sets up a server using openSUSE Leap and uses only packages that are in the overlapping set between Leap and SLES that user can have a business action only switch from Leap to SLES. Since the packages are already signed by the SUSE key everything in the support system just works once the user is enabled on the business end.
That doesn't work for all cases of course. When a user has a system that use KDE and wants support then the user cannot get support for KDE as SLES + Workstation Extension or SLED support GNOME. However, since KDE is in PackageHub the user can still get support for all the packages signed by the SUSE key.
Hope this helps in illustrating the advantages for the user w.r.t. using one signing key vs. the other.
I do see the benefit this will bring for some folks but hope to limit the consequences for others.
Are some numbers available how often Leap to SLE switches happen compared to the number of all Leap user installs? And perhaps how often complains are raised because of the need to reinstall packages?
Please let me exaggerate a little bit: Are we trading saving bandwidth for those wanting to switch at the price of requiring all Leap users to add and trust a signing key of an entity that might follow rules not controlled by openSUSE?
I don't want to argue against having SUSE signed binaries in the openSUSE repositories but would really prefer if a technical solution can be found, where this is not the only signature.
With such multi-signed packages Leap users can solely rely on the openSUSE signature, while those switching to SLE (what has to include adding trust to the SUSE key) have SUSE signatures already available for shared packages without need to reinstall.
We can just resign packages without rebuilding them. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
reply to Neal Gompa: [...]
We can just resign packages without rebuilding them.
Yes, after obs verified by rebuilding that it would have created the same binary as produced by SUSE internals. And "resign" in the sense of "adding" a second (openSUSE) signature, not in the sense of "replacing" the existing (SUSE) signature. Of course this has to be supported by the tools used (repeating posted link [1]). Is this possible? cunix [1] https://github.com/rpm-software-management/rpm/pull/1050 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tue, Apr 14, 2020 at 10:57 AM cunix <cunix@gmx.net> wrote:
reply to Neal Gompa: [...]
We can just resign packages without rebuilding them.
Yes, after obs verified by rebuilding that it would have created the same binary as produced by SUSE internals.
And "resign" in the sense of "adding" a second (openSUSE) signature, not in the sense of "replacing" the existing (SUSE) signature.
Of course this has to be supported by the tools used (repeating posted link [1]).
Is this possible?
Not that. But we can replace signatures without touching the payload. rpm-sign can delete and add signatures, and so can obs-signd. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
reply to Neal Gompa:
On Tue, Apr 14, 2020 at 10:57 AM cunix <cunix@gmx.net> wrote:
reply to Neal Gompa: [...]
We can just resign packages without rebuilding them.
Yes, after obs verified by rebuilding that it would have created the same binary as produced by SUSE internals.
And "resign" in the sense of "adding" a second (openSUSE) signature, not in the sense of "replacing" the existing (SUSE) signature.
Of course this has to be supported by the tools used (repeating posted link [1]).
Is this possible?
Not that. But we can replace signatures without touching the payload. rpm-sign can delete and add signatures, and so can obs-signd.
While I'd like to have packages from the official openSUSE repositories signed by an openSUSE key, I got the impression others prefer to have a SUSE signature for shared packages. If this is one or the other, there seems to be a conflict hard to solve. Therefore I would prefer a solution where we can have both at the same time. cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Dienstag, 14. April 2020, 16:24:20 CEST wrote Neal Gompa:
On Tue, Apr 14, 2020 at 10:20 AM cunix <cunix@gmx.net> wrote:
reply to Robert Schweikert:
On 4/11/20 5:41 AM, Simon Lees wrote:
On 4/11/20 9:20 AM, cunix wrote:
If openSUSE users should use binaries from a build instance they can't control or look into, there really needs to be a way they can trust it the same way as obs - Adrian Schroeter already said so previously. Otherwise various package "forks" on obs may arise.
What is the problem with rebuilding the SLE binaries on obs for openSUSE? Saving build power?
Packages built on openSUSE's build server are signed with openSUSE certificates where as packages built on SUSE's build server are signed with SUSE certificates which would mean the packages would still be different.
And this is a very important consideration from a support perspective. One part of this is that a user can switch from openSUSE to SLES without having to re-install/switch a bunch of packages.
Example:
If a user sets up a server using openSUSE Leap and uses only packages that are in the overlapping set between Leap and SLES that user can have a business action only switch from Leap to SLES. Since the packages are already signed by the SUSE key everything in the support system just works once the user is enabled on the business end.
That doesn't work for all cases of course. When a user has a system that use KDE and wants support then the user cannot get support for KDE as SLES + Workstation Extension or SLED support GNOME. However, since KDE is in PackageHub the user can still get support for all the packages signed by the SUSE key.
Hope this helps in illustrating the advantages for the user w.r.t. using one signing key vs. the other.
I do see the benefit this will bring for some folks but hope to limit the consequences for others.
Are some numbers available how often Leap to SLE switches happen compared to the number of all Leap user installs? And perhaps how often complains are raised because of the need to reinstall packages?
Please let me exaggerate a little bit: Are we trading saving bandwidth for those wanting to switch at the price of requiring all Leap users to add and trust a signing key of an entity that might follow rules not controlled by openSUSE?
I don't want to argue against having SUSE signed binaries in the openSUSE repositories but would really prefer if a technical solution can be found, where this is not the only signature.
With such multi-signed packages Leap users can solely rely on the openSUSE signature, while those switching to SLE (what has to include adding trust to the SUSE key) have SUSE signatures already available for shared packages without need to reinstall.
We can just resign packages without rebuilding them.
we could do that, but I do not see the point acutally. 1) resigning makes security always weaker because it does not happen in the origin anymore. 2) the package signing is not very important in practice. zypp stack is verifing signature of the repository meta data and also the %_vendor of the rpms. But the package signature itself is not verified (only indirectly via the hash sum of the entire file). So making the security weaker and dealing with the same files twice with different signatures is not giving any advantage from my POV. -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wed, Apr 15, 2020 at 7:04 AM Adrian Schröter <adrian@suse.de> wrote:
On Dienstag, 14. April 2020, 16:24:20 CEST wrote Neal Gompa:
On Tue, Apr 14, 2020 at 10:20 AM cunix <cunix@gmx.net> wrote:
reply to Robert Schweikert:
On 4/11/20 5:41 AM, Simon Lees wrote:
On 4/11/20 9:20 AM, cunix wrote:
If openSUSE users should use binaries from a build instance they can't control or look into, there really needs to be a way they can trust it the same way as obs - Adrian Schroeter already said so previously. Otherwise various package "forks" on obs may arise.
What is the problem with rebuilding the SLE binaries on obs for openSUSE? Saving build power?
Packages built on openSUSE's build server are signed with openSUSE certificates where as packages built on SUSE's build server are signed with SUSE certificates which would mean the packages would still be different.
And this is a very important consideration from a support perspective. One part of this is that a user can switch from openSUSE to SLES without having to re-install/switch a bunch of packages.
Example:
If a user sets up a server using openSUSE Leap and uses only packages that are in the overlapping set between Leap and SLES that user can have a business action only switch from Leap to SLES. Since the packages are already signed by the SUSE key everything in the support system just works once the user is enabled on the business end.
That doesn't work for all cases of course. When a user has a system that use KDE and wants support then the user cannot get support for KDE as SLES + Workstation Extension or SLED support GNOME. However, since KDE is in PackageHub the user can still get support for all the packages signed by the SUSE key.
Hope this helps in illustrating the advantages for the user w.r.t. using one signing key vs. the other.
I do see the benefit this will bring for some folks but hope to limit the consequences for others.
Are some numbers available how often Leap to SLE switches happen compared to the number of all Leap user installs? And perhaps how often complains are raised because of the need to reinstall packages?
Please let me exaggerate a little bit: Are we trading saving bandwidth for those wanting to switch at the price of requiring all Leap users to add and trust a signing key of an entity that might follow rules not controlled by openSUSE?
I don't want to argue against having SUSE signed binaries in the openSUSE repositories but would really prefer if a technical solution can be found, where this is not the only signature.
With such multi-signed packages Leap users can solely rely on the openSUSE signature, while those switching to SLE (what has to include adding trust to the SUSE key) have SUSE signatures already available for shared packages without need to reinstall.
We can just resign packages without rebuilding them.
we could do that, but I do not see the point acutally.
1) resigning makes security always weaker because it does not happen in the origin anymore.
2) the package signing is not very important in practice. zypp stack is verifing signature of the repository meta data and also the %_vendor of the rpms. But the package signature itself is not verified (only indirectly via the hash sum of the entire file).
So making the security weaker and dealing with the same files twice with different signatures is not giving any advantage from my POV.
Zypp stack is *definitely* not doing that. It verifies the GPG signature on repomd.xml.asc as well as the signatures on the packages. It definitely becomes unhappy when they're mixed. I know this because I've accidentally done this when releasing packages for SLE and openSUSE before, and everyone screamed about it pretty quickly. :) -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mittwoch, 15. April 2020, 13:07:52 CEST wrote Neal Gompa:
On Wed, Apr 15, 2020 at 7:04 AM Adrian Schröter <adrian@suse.de> wrote:
On Dienstag, 14. April 2020, 16:24:20 CEST wrote Neal Gompa:
On Tue, Apr 14, 2020 at 10:20 AM cunix <cunix@gmx.net> wrote:
reply to Robert Schweikert:
On 4/11/20 5:41 AM, Simon Lees wrote:
On 4/11/20 9:20 AM, cunix wrote: > If openSUSE users should use binaries from a build instance they > can't control or look into, there really needs to be a way they > can trust it the same way as obs - Adrian Schroeter already said > so previously. Otherwise various package "forks" on obs may > arise. > > What is the problem with rebuilding the SLE binaries on obs for > openSUSE? Saving build power?
Packages built on openSUSE's build server are signed with openSUSE certificates where as packages built on SUSE's build server are signed with SUSE certificates which would mean the packages would still be different.
And this is a very important consideration from a support perspective. One part of this is that a user can switch from openSUSE to SLES without having to re-install/switch a bunch of packages.
Example:
If a user sets up a server using openSUSE Leap and uses only packages that are in the overlapping set between Leap and SLES that user can have a business action only switch from Leap to SLES. Since the packages are already signed by the SUSE key everything in the support system just works once the user is enabled on the business end.
That doesn't work for all cases of course. When a user has a system that use KDE and wants support then the user cannot get support for KDE as SLES + Workstation Extension or SLED support GNOME. However, since KDE is in PackageHub the user can still get support for all the packages signed by the SUSE key.
Hope this helps in illustrating the advantages for the user w.r.t. using one signing key vs. the other.
I do see the benefit this will bring for some folks but hope to limit the consequences for others.
Are some numbers available how often Leap to SLE switches happen compared to the number of all Leap user installs? And perhaps how often complains are raised because of the need to reinstall packages?
Please let me exaggerate a little bit: Are we trading saving bandwidth for those wanting to switch at the price of requiring all Leap users to add and trust a signing key of an entity that might follow rules not controlled by openSUSE?
I don't want to argue against having SUSE signed binaries in the openSUSE repositories but would really prefer if a technical solution can be found, where this is not the only signature.
With such multi-signed packages Leap users can solely rely on the openSUSE signature, while those switching to SLE (what has to include adding trust to the SUSE key) have SUSE signatures already available for shared packages without need to reinstall.
We can just resign packages without rebuilding them.
we could do that, but I do not see the point acutally.
1) resigning makes security always weaker because it does not happen in the origin anymore.
2) the package signing is not very important in practice. zypp stack is verifing signature of the repository meta data and also the %_vendor of the rpms. But the package signature itself is not verified (only indirectly via the hash sum of the entire file).
So making the security weaker and dealing with the same files twice with different signatures is not giving any advantage from my POV.
Zypp stack is *definitely* not doing that. It verifies the GPG signature on repomd.xml.asc as well as the signatures on the packages. It definitely becomes unhappy when they're mixed.
I know this because I've accidentally done this when releasing packages for SLE and openSUSE before, and everyone screamed about it pretty quickly. :)
I doubt, but we will see during testing the media ... -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
reply to Adrian Schröter:
On Dienstag, 14. April 2020, 16:24:20 CEST wrote Neal Gompa:
On Tue, Apr 14, 2020 at 10:20 AM cunix <cunix@gmx.net> wrote:
reply to Robert Schweikert:
On 4/11/20 5:41 AM, Simon Lees wrote:
On 4/11/20 9:20 AM, cunix wrote:
[...] We can just resign packages without rebuilding them.
we could do that, but I do not see the point acutally.
1) resigning makes security always weaker because it does not happen in the origin anymore.
Does this apply for "adding" (not "replacing") a signature as well?
2) the package signing is not very important in practice. zypp stack is verifing signature of the repository meta data and also the %_vendor of the rpms. But the package signature itself is not verified (only indirectly via the hash sum of the entire file).
Setting "pkg_gpgcheck=1" [1] in a repo file, I would expect zypper not to install a package that is only (rpm) signed by a not trusted key. This should work with the rpm directly [2], no? And of course my hope is this feature won't get lost.
So making the security weaker and dealing with the same files twice with different signatures is not giving any advantage from my POV.
I would argue, from an openSUSE Leap user's perspective, security is only kept at its current level, if a signature from a nowadays trusted (openSUSE) key is included and this signing authority has verified it would have created the same binary (without SUSE signature) before adding its own signature. cunix [1] https://github.com/openSUSE/libzypp/blob/cf056100f41d8023cc027c2ac7f256306a6... [2] https://github.com/openSUSE/libzypp/blob/67f55b474d67f77c1868955da8542a7acfa... -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Donnerstag, 16. April 2020, 22:01:43 CEST wrote cunix:
reply to Adrian Schröter:
On Dienstag, 14. April 2020, 16:24:20 CEST wrote Neal Gompa:
On Tue, Apr 14, 2020 at 10:20 AM cunix <cunix@gmx.net> wrote:
reply to Robert Schweikert:
On 4/11/20 5:41 AM, Simon Lees wrote:
On 4/11/20 9:20 AM, cunix wrote:
[...] We can just resign packages without rebuilding them.
we could do that, but I do not see the point acutally.
1) resigning makes security always weaker because it does not happen in the origin anymore.
Does this apply for "adding" (not "replacing") a signature as well?
No, but IIRC rpm format and/or our tooling is supporting only a single key atm (not checked). In any case it would modify the rpm, so the file would not have the same checksum anymore. That makes it harder to compare. So, I like to avoid this...
2) the package signing is not very important in practice. zypp stack is verifing signature of the repository meta data and also the %_vendor of the rpms. But the package signature itself is not verified (only indirectly via the hash sum of the entire file).
Setting "pkg_gpgcheck=1" [1] in a repo file, I would expect zypper not to install a package that is only (rpm) signed by a not trusted key.
okay, if you enable that it may check rpm signatures in addition. Not our default though.
This should work with the rpm directly [2], no?
And of course my hope is this feature won't get lost.
It should not. What we will do in current setup is basically to import both gpg keys, SLE and openSUSE by default as trusted keys. So, I see no feature to go away, but we keep the transparence and the original package.
So making the security weaker and dealing with the same files twice with different signatures is not giving any advantage from my POV.
I would argue, from an openSUSE Leap user's perspective, security is only kept at its current level, if a signature from a nowadays trusted (openSUSE) key is included and this signing authority has verified it would have created the same binary (without SUSE signature) before adding its own signature.
From my POV is that a Leap user anyway needs to trust SUSE and openSUSE atm. Because the sources are submitted directly. Using two keys and the binaries is making this just more visible to the user. Can you follow me here? bye adrian -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
reply to Adrian Schröter:
On Donnerstag, 16. April 2020, 22:01:43 CEST wrote cunix:
reply to Adrian Schröter:
On Dienstag, 14. April 2020, 16:24:20 CEST wrote Neal Gompa:
On Tue, Apr 14, 2020 at 10:20 AM cunix <cunix@gmx.net> wrote:
reply to Robert Schweikert:
On 4/11/20 5:41 AM, Simon Lees wrote: > On 4/11/20 9:20 AM, cunix wrote:
[...] We can just resign packages without rebuilding them.
we could do that, but I do not see the point acutally.
1) resigning makes security always weaker because it does not happen in the origin anymore.
Does this apply for "adding" (not "replacing") a signature as well?
No, but IIRC rpm format and/or our tooling is supporting only a single key atm (not checked).
Therefore I would propose to wait with shipping a Jump-like approach officially to openSUSE Leap, until the tools are able to work with multiple keys/signatures. Of course this should not stop anyone from setting up and testing Jump already now. Perhaps better solutions are found on the way or other issues occur that might stop this idea - so current tools and their features don't have to be extended.
In any case it would modify the rpm, so the file would not have the same checksum anymore. That makes it harder to compare.
That is probably correct. Perhaps the second (openSUSE) signature can be "back ported" to the SLE binaries making them bitwise identical again? Or the tools used should not rely on the hash of the whole rpm but on the pieces of the rpm that are actually signed?
So, I like to avoid this...
That I do really understand, especially if you are one of the main persons who has/wants to implement this while I'm currently only adding comments from the sideline. Nevertheless I hope you see addressing some of my concerns as a chance to keep trustworthiness and accountability at least at the same level we are enjoying today.
2) the package signing is not very important in practice. zypp stack is verifing signature of the repository meta data and also the %_vendor of the rpms. But the package signature itself is not verified (only indirectly via the hash sum of the entire file).
Setting "pkg_gpgcheck=1" [1] in a repo file, I would expect zypper not to install a package that is only (rpm) signed by a not trusted key.
okay, if you enable that it may check rpm signatures in addition. Not our default though.
This should work with the rpm directly [2], no?
And of course my hope is this feature won't get lost.
It should not.
What we will do in current setup is basically to import both gpg keys, SLE and openSUSE by default as trusted keys.
That was my fear and is the point I'd like to see prevented somehow. Otherwise Leap would only be usable for those not turning "pkg_gpgcheck" on or accepting the SLE key as trusted. Choosing the later, systems under my control would accept any binary with a SLE signature, probably not limited to the official openSUSE Leap repositories, although I'm using and trusting openSUSE, not necessarily SLE. In my opinion openSUSE should only include package signing keys trusted by default that are under full control of openSUSE. openSUSE Leap should only ask its users to fully trust a key, that openSUSE (and only openSUSE) can create/revoke/regenerate/access/use for signing etc. without relying on a third party that might follow different rules and is not governed by openSUSE. What would be the answer if some other entity asks openSUSE to include and trust its packaging keys in Leap by default in order to create a better user experience when installing binaries from this entity?
So, I see no feature to go away, but we keep the transparence and the original package.
The second signature would in my opinion keep and improve the transparency. Having to trust either the SLE key, turn off pkg_gpgcheck or stop using Leap is in my view sort of a regression.
So making the security weaker and dealing with the same files twice with different signatures is not giving any advantage from my POV.
I would argue, from an openSUSE Leap user's perspective, security is only kept at its current level, if a signature from a nowadays trusted (openSUSE) key is included and this signing authority has verified it would have created the same binary (without SUSE signature) before adding its own signature.
From my POV is that a Leap user anyway needs to trust SUSE and openSUSE atm. Because the sources are submitted directly.
This seems to be a point where we are not completely on the same page, perhaps because you're looking from the inside while I do not have the same insight and have always to take into consideration that I'm not getting the whole picture because knowledge about some shady corners is not publicly shared. As said previously, this might not be rational and I really don't want to accuse anybody of any wrong doing and this is nothing personal. Hopefully you understand the saying "Trust is good, control is better." Therefore I do trust the binaries build by obs based on sources coming from SLE, because obs is sufficiently open for me to look into the build process. I can't say the same for the internal SUSE build setup. Consequently I would prefer if obs verifies the binaries build for SLE are indeed those that obs would have produced (before publishing). The fact that this verification was successful should be expressed by adding the (second) openSUSE signature. If this can be only discovered some time after publishing by someone who tries to reproduce the build, gets different results and might have no clue for the reason because of lacking insight into the SUSE internal build config/service, this in in my view too late and not really effective.
Using two keys and the binaries is making this just more visible to the user.
What I see as a good thing in regard to transparency.
Can you follow me here?
I do understand you and might have a similar view if I would find myself in the position having to implement this. It is one possibility to add the SLE signing key. Having to adapt the complete tool chain is way more complicated and probably not achievable in the time frame that was communicated. Nevertheless "trust" is a touchy thing and granting it by default to an entity that is not controlled by openSUSE should in my opinion not be done if other ways are possible, although more complicated. Please don't think I'm fundamentally against your idea to implement something like Jump. I do see some benefits, but want to raise at an early stage awareness of things/users/trust that might get lost and propose ways how your idea might be improved.
bye adrian
bye cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Freitag, 17. April 2020, 18:52:56 CEST wrote cunix:
reply to Adrian Schröter:
On Donnerstag, 16. April 2020, 22:01:43 CEST wrote cunix:
reply to Adrian Schröter:
On Dienstag, 14. April 2020, 16:24:20 CEST wrote Neal Gompa:
On Tue, Apr 14, 2020 at 10:20 AM cunix <cunix@gmx.net> wrote:
reply to Robert Schweikert: > On 4/11/20 5:41 AM, Simon Lees wrote: >> On 4/11/20 9:20 AM, cunix wrote:
[...] We can just resign packages without rebuilding them.
we could do that, but I do not see the point acutally.
1) resigning makes security always weaker because it does not happen in the origin anymore.
Does this apply for "adding" (not "replacing") a signature as well?
No, but IIRC rpm format and/or our tooling is supporting only a single key atm (not checked).
Therefore I would propose to wait with shipping a Jump-like approach officially to openSUSE Leap, until the tools are able to work with multiple keys/signatures.
AFAIK, it would be an incompatible change in rpm's binary format. So nothing what I hope for soon. However, we could of course also find an indepdend way of signing it detached. Means into another file. (but on the other hand this more or less the same as the openSUSE signed rpm-md data).
Of course this should not stop anyone from setting up and testing Jump already now.
And nothing else is what we do atm :)
Perhaps better solutions are found on the way or other issues occur that might stop this idea - so current tools and their features don't have to be extended.
In any case it would modify the rpm, so the file would not have the same checksum anymore. That makes it harder to compare.
That is probably correct.
Perhaps the second (openSUSE) signature can be "back ported" to the SLE binaries making them bitwise identical again?
Or the tools used should not rely on the hash of the whole rpm but on the pieces of the rpm that are actually signed?
I think we should first come to a conclusion what this second signature should tell in first place. And if we can not achieve it in a different way. So, it basically means that openSUSE approved this particular SLE package for usage with an official openSUSE distribution. Right? ...
What we will do in current setup is basically to import both gpg keys, SLE and openSUSE by default as trusted keys.
That was my fear and is the point I'd like to see prevented somehow.
Otherwise Leap would only be usable for those not turning "pkg_gpgcheck" on or accepting the SLE key as trusted.
I am not sure if that really breaks this option, since it would be still be a trusted key imported into rpm database. However, it should be much more easy to adapt this functionality since it does not involve a new rpm binary format.
Choosing the later, systems under my control would accept any binary with a SLE signature, probably not limited to the official openSUSE Leap repositories, although I'm using and trusting openSUSE, not necessarily SLE.
In my opinion openSUSE should only include package signing keys trusted by default that are under full control of openSUSE.
okay, so it would be an option to have method to accept the SLE signed package only if it is signed by meta data signed by openSUSE? Would that be a solution? That should be solvable in zypp tooling IMHO (not checked with zypp developers).
openSUSE Leap should only ask its users to fully trust a key, that openSUSE (and only openSUSE) can create/revoke/regenerate/access/use for signing etc. without relying on a third party that might follow different rules and is not governed by openSUSE.
What would be the answer if some other entity asks openSUSE to include and trust its packaging keys in Leap by default in order to create a better user experience when installing binaries from this entity?
I don't know. Depends on the entity and the reason. But this other entity is not providing already the core content of the distro, so I am not sure if that is a good analogy.
So, I see no feature to go away, but we keep the transparence and the original package.
The second signature would in my opinion keep and improve the transparency.
Having to trust either the SLE key, turn off pkg_gpgcheck or stop using Leap is in my view sort of a regression.
k, I can follow you here. But maybe this can be solved by my proposal to require the openSUSE key in addition for the metadata.
So making the security weaker and dealing with the same files twice with different signatures is not giving any advantage from my POV.
I would argue, from an openSUSE Leap user's perspective, security is only kept at its current level, if a signature from a nowadays trusted (openSUSE) key is included and this signing authority has verified it would have created the same binary (without SUSE signature) before adding its own signature.
From my POV is that a Leap user anyway needs to trust SUSE and openSUSE atm. Because the sources are submitted directly.
This seems to be a point where we are not completely on the same page, perhaps because you're looking from the inside while I do not have the same insight and have always to take into consideration that I'm not getting the whole picture because knowledge about some shady corners is not publicly shared.
As said previously, this might not be rational and I really don't want to accuse anybody of any wrong doing and this is nothing personal.
Hopefully you understand the saying "Trust is good, control is better."
Yes, and therefore we agreed that the option of reproducibility is a hard requirement.
Therefore I do trust the binaries build by obs based on sources coming from SLE, because obs is sufficiently open for me to look into the build process. I can't say the same for the internal SUSE build setup.
well, it is the same technology, just a different instance. So the build should be (has to) reproducible.
Consequently I would prefer if obs verifies the binaries build for SLE are indeed those that obs would have produced (before publishing).
The fact that this verification was successful should be expressed by adding the (second) openSUSE signature.
I will setup another project in the next days to try to rebuild the SUSE:SLE-15:GA project in build.opensuse.org. So we have maybe a starting point of the discussion how to verify. But given the rpm format limitation I see the second signature inside of the rpm critical. We could think about to sign something detached though... ...
Please don't think I'm fundamentally against your idea to implement something like Jump. I do see some benefits, but want to raise at an early stage awareness of things/users/trust that might get lost and propose ways how your idea might be improved.
yes, thank you. And please do not think we know already how to implement it. There are many open questions indeed and the failure of the project is still an option :) -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wed, Apr 22, 2020 at 09:27, Adrian Schröter <adrian@suse.de> wrote:
On Freitag, 17. April 2020, 18:52:56 CEST wrote cunix:
Therefore I would propose to wait with shipping a Jump-like approach officially to openSUSE Leap, until the tools are able to work with multiple keys/signatures.
AFAIK, it would be an incompatible change in rpm's binary format. So nothing what I hope for soon.
https://github.com/rpm-software-management/rpm/projects/4 it is being worked on upstream though, I wouldn't call it unfeasible ;) (I gotta suggest signify as a replacement for pgp since I really want that to happen though, thanks for a reminder) LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mittwoch, 22. April 2020, 09:40:01 CEST wrote Stasiek Michalski:
On Wed, Apr 22, 2020 at 09:27, Adrian Schröter <adrian@suse.de> wrote:
On Freitag, 17. April 2020, 18:52:56 CEST wrote cunix:
Therefore I would propose to wait with shipping a Jump-like approach officially to openSUSE Leap, until the tools are able to work with multiple keys/signatures.
AFAIK, it would be an incompatible change in rpm's binary format. So nothing what I hope for soon.
https://github.com/rpm-software-management/rpm/projects/4 it is being worked on upstream though, I wouldn't call it unfeasible ;) (I gotta suggest signify as a replacement for pgp since I really want that to happen though, thanks for a reminder)
Ah, cool. Then there is hope indeed :) Do you know if rpm will handle the signatures with an "and" or "or" requirement? I mean, will it check if both signatures are valid or only one of them? -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wed, Apr 22, 2020 at 09:46, Adrian Schröter <adrian@suse.de> wrote:
On Mittwoch, 22. April 2020, 09:40:01 CEST wrote Stasiek Michalski:
https://github.com/rpm-software-management/rpm/projects/4 it is being worked on upstream though, I wouldn't call it unfeasible ;) (I gotta suggest signify as a replacement for pgp since I really want that to happen though, thanks for a reminder)
Ah, cool. Then there is hope indeed :)
Do you know if rpm will handle the signatures with an "and" or "or" requirement? I mean, will it check if both signatures are valid or only one of them?
I believe it's just one, but that's the impression I got from reading the PR description. I suggest talking with rpm guys though, on the open PR and the associated issue, since you probably want your voices heard considering this is something that might come in useful for you if you communicate all that you need in the implementation. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wed, Apr 22, 2020 at 3:46 AM Adrian Schröter <adrian@suse.de> wrote:
On Mittwoch, 22. April 2020, 09:40:01 CEST wrote Stasiek Michalski:
On Wed, Apr 22, 2020 at 09:27, Adrian Schröter <adrian@suse.de> wrote:
On Freitag, 17. April 2020, 18:52:56 CEST wrote cunix:
Therefore I would propose to wait with shipping a Jump-like approach officially to openSUSE Leap, until the tools are able to work with multiple keys/signatures.
AFAIK, it would be an incompatible change in rpm's binary format. So nothing what I hope for soon.
https://github.com/rpm-software-management/rpm/projects/4 it is being worked on upstream though, I wouldn't call it unfeasible ;) (I gotta suggest signify as a replacement for pgp since I really want that to happen though, thanks for a reminder)
Ah, cool. Then there is hope indeed :)
Do you know if rpm will handle the signatures with an "and" or "or" requirement? I mean, will it check if both signatures are valid or only one of them?
I think the idea is that the librpm API will give you that flexibility. Certainly Panu and Florian have been talking to the DNF team about directly using such new APIs with the package manager so that more fine-grained policies can be implemented. It's been a personal point of pain for Panu that most RPM package managers do RPM signature handling in a bad way, according to him. :) -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
reply to Adrian Schröter:
On Freitag, 17. April 2020, 18:52:56 CEST wrote cunix: [...] AFAIK, it would be an incompatible change in rpm's binary format. So nothing what I hope for soon.
If rpm upstream thinks about implementing something similar it should hopefully be usable downstream. Having this done "soon" in rpm and other software that has to be adapted might be a challenge, indeed.
However, we could of course also find an indepdend way of signing it detached. Means into another file. (but on the other hand this more or less the same as the openSUSE signed rpm-md data).
see below [...]
I think we should first come to a conclusion what this second signature should tell in first place. And if we can not achieve it in a different way.
So, it basically means that openSUSE approved this particular SLE package for usage with an official openSUSE distribution.
Right?
Literally speaking, IMHO, it should tell: "I'm the build service of the openSUSE project and do have access to the private part of the openSUSE signing key. I received sources and binaries from some another entity, rebuild this package and hereby guarantee that my build result was the exact same as is included in this rpm file. This I do promise by adding my signature."
What we will do in current setup is basically to import both gpg keys, SLE and openSUSE by default as trusted keys.
That was my fear and is the point I'd like to see prevented somehow.
Otherwise Leap would only be usable for those not turning "pkg_gpgcheck" on or accepting the SLE key as trusted.
I am not sure if that really breaks this option, since it would be still be a trusted key imported into rpm database.
But this is exactly what in my opinion should be avoided: There should be no need to import the SLE key into rpmdb for Leap users. And it should especially not be done by default. Of course users might choose to opt-in explicitly, for example those wanting to switch to SLE. But others should in my opinion be able to enable "pkg_gpgcheck" and/or continue using Leap without having to install or trust the SLE key.
However, it should be much more easy to adapt this functionality since it does not involve a new rpm binary format.
[...]
In my opinion openSUSE should only include package signing keys trusted by default that are under full control of openSUSE.
okay, so it would be an option to have method to accept the SLE signed package only if it is signed by meta data signed by openSUSE?
Would that be a solution?
That should be solvable in zypp tooling IMHO (not checked with zypp developers).
Me talked about something similar in a messages in this thread (as option 5.c), but we were both of the opinion that this increases complexity and is at best a fallback option. Nevertheless, in my opinion slightly better than having to trust the SLE key. Using a solution implemented inside rpm has in my opinion several advantages. For example currently doing rpm -Vvv installedPackage seems to verify that the rpm header is correctly signed and shows via keyID by whom. If we are able to keep the SLE key outside of Leap systems by some kind of zypp workaround but the rpm package still has only a SLE signature, the above rpm command might not be able to verify the installed package (headers) because it has not the SLE public key in the db and is not aware of some detached signature it should consult. This reveals some kind of trust gap between zypper and rpm because the former accepted installation while the later can't verify the installed package. This is not ideal. Thus, in my opinion, a solution where both signatures are available but Leap users can solely rely on the signature coming from openSUSE and completely ignore the additional (first) SUSE signature seems to be more robust. Users switching to SLE can do the opposite (trust SLE and ignore openSUSE) without reinstall.
openSUSE Leap should only ask its users to fully trust a key, that openSUSE (and only openSUSE) can create/revoke/regenerate/access/use for signing etc. without relying on a third party that might follow different rules and is not governed by openSUSE.
What would be the answer if some other entity asks openSUSE to include and trust its packaging keys in Leap by default in order to create a better user experience when installing binaries from this entity?
I don't know. Depends on the entity and the reason. But this other entity is not providing already the core content of the distro, so I am not sure if that is a good analogy.
Yes, sorry. Question was a little bit nasty. In my opinion the answer should always be a clear and unconditional "No", unless openSUSE can control this key in the same way as her own. Thinking about packman, a project somehow closely related to openSUSE, their signing key is not trusted by default in Leap (perhaps I'm wrong here?), or? [...]
Having to trust either the SLE key, turn off pkg_gpgcheck or stop using Leap is in my view sort of a regression.
k, I can follow you here. But maybe this can be solved by my proposal to require the openSUSE key in addition for the metadata.
As said above, might be possible but solving this inside rpm is perhaps a better choice. [...]
Hopefully you understand the saying "Trust is good, control is better."
Yes, and therefore we agreed that the option of reproducibility is a hard requirement.
Do you already have an idea how this requirement will be enforced? Will obs rebuild each package sources coming from SLE and only publish the binary rpm for Leap if the build was successful and identical? Or is this more some kind of policy, meaning the binary is published and shipped to Leap anyway, but interested users are encouraged to rebuild and if they can't reproduce the package, bugs should be filed? [...]
But given the rpm format limitation I see the second signature inside of the rpm critical. We could think about to sign something detached though...
I do understand your concerns. As said above, a detached- or meta signature will solve some problems, but not all and might introduce some new. If this route is followed by investing work in supporting such detach- or meta signatures but it is later realized that this produces some new issues, there might be an incentive to get done by again picking the "quick" solution and just require Leap users to trust the SLE key by default. Therefore, it is in my opinion a "cleaner" solution to go the hard way from the beginning, try to tackle the issue at the root (in the rpm) so that nothing "trust" related has to be changed for Leap users and they are treated equally compared to those using Tumbleweed. [...]
yes, thank you. And please do not think we know already how to implement it. There are many open questions indeed and the failure of the project is still an option :)
Thank you for being open to a discussion about your idea! Hopefully not having solved all issues until 15.3 release is not considered as a failure and there is enough flexibility to start shipping something jumping officially with a later version of Leap in case the tooling is not ready at 15.3 release time. cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Sat, 2020-04-11 at 01:50 +0200, cunix wrote:
reply to Robert Schweikert:
Hi,
Thanks for the answer Robert! [...]
What is the problem with this approach?
Security certifications.
In order to make security certifications for SLE possible the binaries have to be built in the SUSE controlled instance of the build service. thus copying of binaries from the openSUSE Build Service to the SUSE internal build service is not an option.
That is easier to understand.
If openSUSE users should use binaries from a build instance they can't control or look into, there really needs to be a way they can trust it the same way as obs - Adrian Schroeter already said so previously. Otherwise various package "forks" on obs may arise.
What is the problem with rebuilding the SLE binaries on obs for openSUSE? Saving build power? It guarantees that openSUSE Leap and SLE will be the platform, as no macro expansion or project config will change these binaries.
Next thing that big goal is also to offer seamless migrations, as rpm NVRA will be the same and you can just swap the branding packages. I've discussed some ideas such as replace signed rpm headers, use more efficient delta and so, but you'd still have different release etc. What we currently propose which we believe can be achieved in a reasonable timeframe. I'd love to see improvements over next two releases. Both process wise and build-setup wise. Big concern why people hesitate to look at it is really already mentioned certification. Migrated Leap -> SLE product with mixed binaries would be tricky in this regards, or you'd have to replace thousands of rpms. I suppose this effort would be for a way longer run.
[...]
The partner aspect is that we work on features that are under NDA, thus cannot be developed in OBS, until partners make announcements. But we still have to have packages that have these features. Therefore submissions happen in the SUSE internal build service so we have packages for testing. Once the partner announces the features the packages go to the SLE repos and migrate to OBS.
In my example with the openSUSE co-maintainers A and B for package xy, B (she is additionally the SLE maintainer) will probably be the one who prepares the package in the SUSE build service and make it "obs ready" but she is not allowed to talk to A until obs migration.
What happens if A (only openSUSE maintainer) has (technical) reasons to prefer another solution?
Isn't it likely that B has only little room to compromise at this point in time and won't A find himself in a weaker position because of less/later knowledge?
Consequently, to not risk such conflicts, wouldn't B (or her manager) prefer to have B as the only maintainer in charge?
Of course I don't know how often such situation may occur.
[...]
If A wants to change something in xy for Leap, does he has to ask B (via a SLE feature request) first?
Well if A wants to make a change that change should go through a review process via SR such that interested parties can discuss the changes.Nothing should change here since the SR process is/should be common practice.
Aha. My first understanding was, the (openSUSE) maintainers shouldn't submit their changes directly to Leap anymore, but have to first convince (by SR or feature request) the SLE maintainer to accept the change/update for SLE and than this guy has to push the new SLE package version to Leap.
When there is more than 1 maintainer of a package the none of the maintainers should just make changes without having another set of eyes on the changes.
Agree.
[...]
Doesn't this introduce the potential of conflicts (between A and B)?
This potential is no larger than it is today, for every package that has at least 2 maintainers.
O.K. Probably I don't have enough experience here.
While it is most of the time really beneficial to have multiple maintainers, my fear was that disagreement is more likely if one maintainer is openSUSE only while the other's main focus is SLE.
In case of conflict the later may argue only her proposal is acceptable for SLE and if the former does not accept, she will go forward and change (her) SLE package and submit this version to Leap.
[...]
know if we don't try. Maintainers that do not happen to work for SUSE should certainly NOT be considered as "junior" and in openSUSE have equal say to a maintainer that happens to work for SUSE.
That is good to hear.
Later, Robert
Thank you very much, cunix
-- 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
reply to Lubos Kocman:
On Sat, 2020-04-11 at 01:50 +0200, cunix wrote:
reply to Robert Schweikert:
Thanks for the answer, Lubos! [...]
If openSUSE users should use binaries from a build instance they can't control or look into, there really needs to be a way they can trust it the same way as obs - Adrian Schroeter already said so previously. Otherwise various package "forks" on obs may arise.
What is the problem with rebuilding the SLE binaries on obs for openSUSE? Saving build power? It guarantees that openSUSE Leap and SLE will be the platform, as no macro expansion or project config will change these binaries.
Next thing that big goal is also to offer seamless migrations, as rpm NVRA will be the same and you can just swap the branding packages. I've discussed some ideas such as replace signed rpm headers, use more efficient delta and so, but you'd still have different release etc.
What we currently propose which we believe can be achieved in a reasonable timeframe. I'd love to see improvements over next two releases. Both process wise and build-setup wise.
Big concern why people hesitate to look at it is really already mentioned certification. Migrated Leap -> SLE product with mixed binaries would be tricky in this regards, or you'd have to replace thousands of rpms. I suppose this effort would be for a way longer run.
If build power is not the problem, what about the following approach. Packages that should be shared by SLE and Leap are 1. build on internal SUSE build service and signed by SUSE. 2. Sources are submitted from SLE to obs together with hash of SLE build binaries without the signature. 3. obs builds with these new sources. 4. obs compares the hash of the binary it has just build with the one provided from SLE. 5.a. If hashes don't match, obs adds openSUSE signature to its own build result as the only signature and releases it for openSUSE. OR 5.b. If hashes match, obs adds openSUSE signature to SLE binaries and releases for openSUSE. This is what you don't want to do because it breaks certification? OR 5.c. If hashes match, obs releases SLE binaries for openSUSE. Perhaps, in case of 5.c., it might be possible for obs to append some openSUSE signed notice to a meta package confirming the SLE binaries are reproducible on obs. Would be nice if zypper will be able to query this meta package and can be configured to only accept SLE binaries if meta package includes attestation of build reproducibility. Of course this is only a second line of defense and serves only to make SLE binaries more trustworthy for openSUSE users because software releases will always be somehow signed by openSUSE release key, but not necessarily the rpm. If the meta package didn't include the attestation, 5.b. and 5.c. shouldn't have happened in the first place, but 5.a. This way it is the task of the SLE maintainers (with help of openSUSE colleagues) to bring both build setups in line and produce identical results, while openSUSE users can be sure they get binaries that are at least possible to generate with the sources submitted to openSUSE. I would expect the number of packages coming from 5.a. in openSUSE to decrease over time. On migration Leap to SLE only those packages have to be replaced that don't have a SUSE signature in the rpm. On migration SLE to Leap the meta package has to be checked and where openSUSE notices are missing, openSUSE packages should be available to replace the existing SUSE versions. Might this be feasible? [...] cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Samstag, 11. April 2020, 19:50:48 CEST wrote cunix:
reply to Lubos Kocman:
On Sat, 2020-04-11 at 01:50 +0200, cunix wrote: ...
If openSUSE users should use binaries from a build instance they can't control or look into, there really needs to be a way they can trust it the same way as obs - Adrian Schroeter already said so previously. Otherwise various package "forks" on obs may arise.
What is the problem with rebuilding the SLE binaries on obs for openSUSE? Saving build power? It guarantees that openSUSE Leap and SLE will be the platform, as no macro expansion or project config will change these binaries.
Next thing that big goal is also to offer seamless migrations, as rpm NVRA will be the same and you can just swap the branding packages. I've discussed some ideas such as replace signed rpm headers, use more efficient delta and so, but you'd still have different release etc.
What we currently propose which we believe can be achieved in a reasonable timeframe. I'd love to see improvements over next two releases. Both process wise and build-setup wise.
Big concern why people hesitate to look at it is really already mentioned certification. Migrated Leap -> SLE product with mixed binaries would be tricky in this regards, or you'd have to replace thousands of rpms. I suppose this effort would be for a way longer run.
If build power is not the problem, what about the following approach.
It is not the problem.
Packages that should be shared by SLE and Leap are
1. build on internal SUSE build service and signed by SUSE.
2. Sources are submitted from SLE to obs together with hash of SLE build binaries without the signature.
3. obs builds with these new sources.
4. obs compares the hash of the binary it has just build with the one provided from SLE.
5.a. If hashes don't match, obs adds openSUSE signature to its own build result as the only signature and releases it for openSUSE.
OR
5.b. If hashes match, obs adds openSUSE signature to SLE binaries and releases for openSUSE. This is what you don't want to do because it breaks certification?
I do not see what we win with this. I agree that validation of the internal build packages has a value. But why changing the signature? My current idea is to keep the vendor of SLE packages as SLE. It makes it hopefully easier and more transparent to the user to see where the origin of a package is. IMHO this is a plus instead of hiding this information again.
OR
5.c. If hashes match, obs releases SLE binaries for openSUSE.
Perhaps, in case of 5.c., it might be possible for obs to append some openSUSE signed notice to a meta package confirming the SLE binaries are reproducible on obs.
It is definitive a must that the build is reproducible....
Would be nice if zypper will be able to query this meta package and can be configured to only accept SLE binaries if meta package includes attestation of build reproducibility.
... but I do not like the extra complexity of doing this with additional meta data and per package. IMHO the entire repository, which provides the SLE packages either needs to be release or not. The initial GA ftp stream will have the SLE binaries mixed with the Backports and openSUSE add-ons though in my current initial setup. Just the update repos will have them seperated.
Of course this is only a second line of defense and serves only to make SLE binaries more trustworthy for openSUSE users because software releases will always be somehow signed by openSUSE release key, but not necessarily the rpm. If the meta package didn't include the attestation, 5.b. and 5.c. shouldn't have happened in the first place, but 5.a.
This way it is the task of the SLE maintainers (with help of openSUSE colleagues) to bring both build setups in line and produce identical results, while openSUSE users can be sure they get binaries that are at least possible to generate with the sources submitted to openSUSE.
I like to raise the point that having the build in build.opensuse.org repeated is maybe not enough. If you do not trust the admins of SUSE's internal OBS, you can not really trust (me for example;) the admin of build.opensuse.org. (and I do not take this in any way personal) So it would be indeed the best if the rebuild validation of SLE and(!) openSUSE packages would happen at a complete independend instance. Or you may rebuild specific packages using "osc build --vm-type=kvm" and validate the result. You could adapt build-compare for automation of the compare, just let it fail in case of difference in "your" instance. I am happy to help with such a setup though. happy easter again! adrian -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
reply to Adrian Schröter:
On Samstag, 11. April 2020, 19:50:48 CEST wrote cunix:
reply to Lubos Kocman:
On Sat, 2020-04-11 at 01:50 +0200, cunix wrote: [...] If build power is not the problem, what about the following approach.
It is not the problem.
Packages that should be shared by SLE and Leap are
1. build on internal SUSE build service and signed by SUSE.
2. Sources are submitted from SLE to obs together with hash of SLE build binaries without the signature.
3. obs builds with these new sources.
4. obs compares the hash of the binary it has just build with the one provided from SLE.
5.a. If hashes don't match, obs adds openSUSE signature to its own build result as the only signature and releases it for openSUSE.
OR
5.b. If hashes match, obs adds openSUSE signature to SLE binaries and releases for openSUSE. This is what you don't want to do because it breaks certification?
I do not see what we win with this. I agree that validation of the internal build packages has a value. But why changing the signature?
My hope was that "changing" signature is not the same as replacing it, but adding a second one from openSUSE to the existing SUSE signature. That is currently not possible?: https://github.com/rpm-software-management/rpm/pull/1050 The "win" should have been that Leap users are not required to accept and trust the SUSE signing key. This is necessary with Jump?
My current idea is to keep the vendor of SLE packages as SLE. It makes it hopefully easier and more transparent to the user to see where the origin of a package is. IMHO this is a plus instead of hiding this information again.
I didn't want to hide it and hoped user or system can detect it by checking if rpm has one (openSUSE) or two (openSUSE and SUSE) signatures.
OR
5.c. If hashes match, obs releases SLE binaries for openSUSE.
Perhaps, in case of 5.c., it might be possible for obs to append some openSUSE signed notice to a meta package confirming the SLE binaries are reproducible on obs.
It is definitive a must that the build is reproducible....
Very good.
Would be nice if zypper will be able to query this meta package and can be configured to only accept SLE binaries if meta package includes attestation of build reproducibility.
... but I do not like the extra complexity of doing this with additional meta data and per package.
I didn't like it either but would prefer it compared to a situation where Leap users can only rely on a non openSUSE signature. [...]
This way it is the task of the SLE maintainers (with help of openSUSE colleagues) to bring both build setups in line and produce identical results, while openSUSE users can be sure they get binaries that are at least possible to generate with the sources submitted to openSUSE.
I like to raise the point that having the build in build.opensuse.org repeated is maybe not enough. If you do not trust the admins of SUSE's internal OBS, you can not really trust (me for example;) the admin of build.opensuse.org. (and I do not take this in any way personal)
You are probably right and of course this is nothing personal. Currently every openSUSE user has to trust at least the openSUSE key. Asking all Leap users to additionally trust a (really sorry: "third party") SUSE key might be too much. For you guys inside SUSE this is probably hard to follow and it might not be very rational: From the outside these special SLE things are hard to understand and when reading about non disclosure agreements, certifications and special partner handling there might be some sentiment of seeing this as a little black box some users are not able to grant the same level of trust as for obs.
So it would be indeed the best if the rebuild validation of SLE and(!) openSUSE packages would happen at a complete independend instance.
Agree. At least on my side build power would be kind of a problem ;)
Or you may rebuild specific packages using "osc build --vm-type=kvm" and validate the result.
You could adapt build-compare for automation of the compare, just let it fail in case of difference in "your" instance.
I am happy to help with such a setup though.
Thanks. Out of convenience I would prefer not having to think about having to do something similar before installing SLE/SUSE signed packages because they are additionally signed by an openSUSE key that is already trusted.
happy easter again! adrian
Happy Easter, cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Sun 2020-04-12, cunix wrote:
For you guys inside SUSE this is probably hard to follow and it might not be very rational:
I think I actually understand where you are coming from. Let me share from my own experience:
From the outside these special SLE things are hard to understand and when reading about non disclosure agreements, certifications and special partner handling there might be some sentiment of seeing this as a little black box some users are not able to grant the same level of trust as for obs.
From an engineering perspective product development (minus the planning and administration) and building are pretty similar to what you see on
Those "special SLE things" like non disclosure agreements (that may give SUSE earlier access to code from partners while they are in the process of upstreaming, but largely are there for joint planning these days), certifications (which happen after the product is more or less done), and other considerations usually happen "outside" or around the product and its actual development and building. the openSUSE side. In other words, it's probably okay, if not best, to ignore most references to most of those "enterprise processes". ;-) Think of two kitchens (~ build service) sourcing their ingredients from the same markets, shops and farms (~ upstream projects) using the same recipes (~ spec files etc) with qualified cooks (~ packagers, release managers, UX folks, testers,...) served by friendly waiters who are happy to answer any questions (~ supporters, doc folks). One kitchen guarantees you can have certain menu items for 13+ years and reach them via an 800 number, and they'll serve food 24x7 wearing green polo shirts with a company logo, matching the one on the starched table cloth, whereas the other place may appear a bit more, umm, unorthodox, while both serve comparable food and you don't have to worry about GMO let alone food poisoning in either case. (Disclaimer: Like most analogies this one is far from perfect and mostly intended for your entertainment. :-) Gerald -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
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? 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. 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. No, I don't have business reasons. I just want to have a (half-way) modern toolchain. 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". Wolfgang -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thu, 2020-04-16 at 14:03 +0200, Wolfgang Rosenauer wrote:
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.
No, I don't have business reasons. I just want to have a (half-way) modern toolchain.
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".
Wolfgang
Wolfgang, I would just like to add my voice in support to everything you say here. Without indulging in a post of my usual verbosity, I think the importance of ensuring that openSUSE contributors can contribute has not been given the priority it deserves. I share your frustration. My own contributions to Leap have been hindered in much the same way that you describe here, and it has an impact on my own motivations to continue contributing to Leap much as you describe here. While I have some hope that this proposal might bring solutions to these problems, I think more care needs to be taken to address the stated issues up front. Failure to address concerns like Wolfgangs risk increasing frustrations, and that is how volunteers are lost. Lost volunteers are not only hard to get back, but no matter how amicable a parting, losing volunteers in this manner is likely to make it harder for us to recruit new blood. Such a situation risks making the view "Leap/Jump is an entirely corporate affair" a self-fufilling prophecy unless great care is made to show the opposite is true at the earliest opportunity. Regards, Richard -- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
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
On Thu 2020-04-16, Wolfgang Rosenauer wrote:
My main concern is though and it's not totally new:
This is a fair concern, and one that we (openSUSE, SUSE,...) absolutely need to address -- and not just because of the current proposal, since as you point out your experience predates that.
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").
Two immediate reactions: (1) Going forward I wish for us to change the default response to such a request that comes with an offer to do a key part of the work from "No, unless there is a good reason" to "Yes, unless there is a good reason". That does not mean that changing the default version of GCC becomes super likely, and non-code aspects such as QA efforts also will need to be considered, but "no business reasoning" ... rather not.
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.
And (2), moving things from openSUSE behind closed doors is unfortunate at best. We need to improve processes and tools to support more openness. On Thu 2020-04-16, Richard Brown wrote:
Without indulging in a post of my usual verbosity, I think the importance of ensuring that openSUSE contributors can contribute has not been given the priority it deserves.
Yes. Full stop. We need to improve tooling, processes, and then live that day to day. On Thu 2020-04-16, Lubos Kocman wrote:
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.
+1
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
Thank you for doing that, Lubos! Gerald -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
reply to Gerald Pfeifer:
On Sun 2020-04-12, cunix wrote:
For you guys inside SUSE this is probably hard to follow and it might not be very rational:
I think I actually understand where you are coming from. Let me share from my own experience:
Thank you for the answer Gerald!
From the outside these special SLE things are hard to understand and when reading about non disclosure agreements, certifications and special partner handling there might be some sentiment of seeing this as a little black box some users are not able to grant the same level of trust as for obs.
Those "special SLE things" like non disclosure agreements (that may give SUSE earlier access to code from partners while they are in the process of upstreaming, but largely are there for joint planning these days), certifications (which happen after the product is more or less done), and other considerations usually happen "outside" or around the product and its actual development and building.
From an engineering perspective product development (minus the planning and administration) and building are pretty similar to what you see on the openSUSE side. In other words, it's probably okay, if not best, to ignore most references to most of those "enterprise processes". ;-)
I do see your point and thank you for sharing your perspective. Nevertheless some kind of unbalance will probably remain because non-SUSE openSUSE people might only get "second-hand" information from what happens inside SLE/SUSE. As long as both projects don't follow the same rules and are equally open, granting the same level of trust is really hard.
Think of two kitchens (~ build service) sourcing their ingredients from the same markets, shops and farms (~ upstream projects) using the same recipes (~ spec files etc) with qualified cooks (~ packagers, release managers, UX folks, testers,...) served by friendly waiters who are happy to answer any questions (~ supporters, doc folks).
One kitchen guarantees you can have certain menu items for 13+ years and reach them via an 800 number, and they'll serve food 24x7 wearing green polo shirts with a company logo, matching the one on the starched table cloth, whereas the other place may appear a bit more, umm, unorthodox, while both serve comparable food and you don't have to worry about GMO let alone food poisoning in either case.
Nice :)
(Disclaimer: Like most analogies this one is far from perfect and mostly intended for your entertainment. :-)
I'll try to stay with your picture - so the same disclaimer should apply and it should not be considered too serious: While getting hopefully the same lunch from both, I can see through the windows of the later kitchen and even enter it, look over the cook's shoulders, propose to use some more salt, or even decide to step up and take his job, if he has left. In a future with more meals coming from the former kitchen, the later gets somehow reduced to a food delivery service (for the shared packages). Cooks currently working here might loose knowledge how to cook properly because they can only propose changes for the recipes to those working in the company kitchen, but they are not able/allowed to enter it. They can continue to create some ice cream or puddings for the broader audience, but working on the main meal will be done more often at home because this task is done by those with green polo shirts. What I'm asking for with keeping the inclusion of an openSUSE signature is some kind of stamp/attestation/guarantee by the food delivery service, that the meal produced by the company kitchen is indeed the same that would have been created in the community kitchen. This should help to prevent the delivery of rotten food. As consumer I choose and therefore trust the delivery service as the last joint of the food production chain where I'm getting my food from but have only limited influence where and how the food is produced. Each part of this chain chooses its next joint upwards (~ trust) and is responsible downwards (~ signature). So, the relationship between company kitchen owner and consumer is only indirect. If nevertheless some day recipe and meal don't match up or an alien element is found in the food, consumers will raise their complains to the delivery service. The delivery service has to be accountable and should not be able to only advice the consumer to negotiate with the company kitchen owner, because the consumer has lost the receipt (~ no openSUSE signature in rpm) proving where he once got the lunch from. Because of the not existing direct relationship between consumer and company kitchen owner, the later will probably ignore such complains from consumers who can't prove any production failures because they are not allowed to enter and look into the kitchen/factory. They would have to send the remaining food to some special lab that is able to reverse engineer the meal and deduce if there was only added some pepper in the wrong place of the meal or if in the worst case meat from a horse grown up near the Dardanelles was included by farmer or cooks following advice from the kitchen owner (who follows himself some sort of request from a "partner"). Therefore, in my opinion, until the company kitchen can be entered the same way as the community kitchen and all cooks are bound by the same rules, which are enforced by the same entity, consumers need at least more ways (~ multiple signature) to trace the path of the food production and delivery process in order to provide clear accountabilities. To not make false claims, the delivery service (~ obs for openSUSE Leap) has to verify build reproducibility, before adding its signature (not replacing the SUSE sig).
Gerald
cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 4/11/20 3:09 AM, cunix wrote:
reply to Stasiek Michalski:
[...]
3. Build openSUSE Leap 15.3 with SLE binaries included by default (assuming community agreement).
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.
Might be nice if it can be done the other way around:
Those SUSE packagers can submit their SLE changes to openSUSE packages or start to maintain them, where no maintainer is in charge.
SUSE's current policy is that all SLE changes should first be submitted to the openSUSE package in tumbleweed (this means the change will be in the next major SLE release) as a part of that the SLE maintainer should already also be one of the openSUSE maintainers and should already be working with any of the other openSUSE contributors to get chagnes into Leap when needed (This isn't always happening perfectly yet). -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Thu 2020-04-09, Stasiek Michalski wrote:
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.
I feel good about it. The way I see openSUSE and SUSE Linux Enterprise engage is an ongoing cooperation (both ways), a dance, sometimes closer, sometimes a bit more independently. Think rumba or salsa more than waltz. :-) In fact, it doesn't just go "both ways", but really "many connected and intertwined ways" - supporting, challenging, pulling together. And it's not two distinct groups of, say, developers, "the community" vs "the SUSE people". It's much more nuanced and intertwined than that (which, to be clear, you never indicated otherwise). And nurturing, supporting, and growing these numerous pathways and clusters, that's a key part of our work
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.
Isn't Jump more like $JUMP, its actual name to be determined? Gerald -- Dr. Gerald Pfeifer <gp@suse.com>, CTO @SUSE + chair @openSUSE -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 4/14/20 6:20 AM, Gerald Pfeifer wrote:
On Thu 2020-04-09, Stasiek Michalski wrote:
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.
I feel good about it.
The way I see openSUSE and SUSE Linux Enterprise engage is an ongoing cooperation (both ways), a dance, sometimes closer, sometimes a bit more independently. Think rumba or salsa more than waltz. :-)
In fact, it doesn't just go "both ways", but really "many connected and intertwined ways" - supporting, challenging, pulling together.
And it's not two distinct groups of, say, developers, "the community" vs "the SUSE people". It's much more nuanced and intertwined than that (which, to be clear, you never indicated otherwise).
And nurturing, supporting, and growing these numerous pathways and clusters, that's a key part of our work
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.
Isn't Jump more like $JUMP, its actual name to be determined?
Gerald
$0.02: if the 'coming closer' ends up with less flexibility than currently available in/with use of opensuse, then it will simply be LESS likely that there will be more migration (aka $revenue) -- immediate or eventual -- to commercially supported SLE. NOT because it's not a simpler/easier migration from the new $JUMP release to SLE, but because there will simply be less use of opensuse. that's imo & 'here'. clearly, not the same for every enterprise. and yes, 'flexibility' is the fuzzy concept. as far as naming, if "The focus of its development is creating usable open-source tools for software developers and system administrators, while providing a user-friendly desktop and feature-rich server environment." continues to be true ... it matters not one whit. whatever TheName(tm) ends up being, explain what the different distros are on the webpage. done. *suse is not targeted to clueless brandname-adopters to begin with, and i'm hard-pressed to believe that any (in)significant numbers were lost due to 'Leap' or 'Tumbleweed' "sub-names" springing forth. and any enterprise _deployer_ that chooses the product based simply on name should be ... re-distributed quickly. personally, i don't care if it's called "openSUSE Bob 99.1"; what it _is_ is what matters. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 4/15/20 12:44 AM, PGNet Dev wrote:
On 4/14/20 6:20 AM, Gerald Pfeifer wrote:
On Thu 2020-04-09, Stasiek Michalski wrote:
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.
I feel good about it.
The way I see openSUSE and SUSE Linux Enterprise engage is an ongoing cooperation (both ways), a dance, sometimes closer, sometimes a bit more independently. Think rumba or salsa more than waltz. :-)
In fact, it doesn't just go "both ways", but really "many connected and intertwined ways" - supporting, challenging, pulling together.
And it's not two distinct groups of, say, developers, "the community" vs "the SUSE people". It's much more nuanced and intertwined than that (which, to be clear, you never indicated otherwise).
And nurturing, supporting, and growing these numerous pathways and clusters, that's a key part of our work
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.
Isn't Jump more like $JUMP, its actual name to be determined?
Gerald
$0.02:
if the 'coming closer' ends up with less flexibility than currently available in/with use of opensuse, then it will simply be LESS likely that there will be more migration (aka $revenue) -- immediate or eventual -- to commercially supported SLE.
One thing to consider is that we are already `very close` Leap and SLE already share much of the same source and much effort has gone into this proposal and the changes that do need to be made to ensure that we are not any less flexible then we already are. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 4/14/20 11:59 PM, Simon Lees wrote:
$0.02:
if the 'coming closer' ends up with less flexibility than currently available in/with use of opensuse, then it will simply be LESS likely that there will be more migration (aka $revenue) -- immediate or eventual -- to commercially supported SLE.
One thing to consider is that we are already `very close` Leap and SLE already share much of the same source and much effort has gone into this proposal and the changes that do need to be made to ensure that we are not any less flexible then we already are.
sure. proof will be in the pudding, of course. given the hypothetical discussion here, it's a bit ... opaque ... as to what $JUMP 'will be'. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Am 14.04.20 um 15:20 schrieb Gerald Pfeifer:
Isn't Jump more like $JUMP, its actual name to be determined?
Let's hope so. Leap 15.0 number was also "just because I needed to set something up in OBS" but then never changed to the much more sane Leap 150. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 4/9/20 2:09 PM, Stasiek Michalski wrote:
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.
The whole point of releasing your software under a free license is to allow it to be re-used by other projects and commercial products. openSUSE isn't also solely the product of the openSUSE community but of a lot of companies (just look at kernel stats [1]) and many other communities and Linux distributions due to a lot of fixes and improvements coming from upstream. Other distributions like Debian, Fedora, Gentoo and Arch are upstream to many other derivatives and most distributions maintainers seem to be okay with the idea that code under an open-source license gets re-used in other projects and products. Adrian
[1] https://lwn.net/Articles/780271/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
* Stasiek Michalski <hellcp@opensuse.org> [01-01-70 12:34]: [...]
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.
fwiw, I believe "Jump" or "JUMP" to be and excellent choice and synonymous with "LEAP". And users will understand the choice. And "LEAP" and "JUMP" are both quite common words. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tuesday 2020-04-14 16:58, Patrick Shanahan wrote:
* Stasiek Michalski <hellcp@opensuse.org> [01-01-70 12:34]: [...]
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.
And "LEAP" and "JUMP" are both quite common words.
Which... is not necessarily a good thing - just think of projects like "FUSE" which will get you google results for DIY markets rather than the filesystem. And with Jump you may just get foot- and sportswear. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thu, Apr 9, 2020 at 6:59 AM Gerald Pfeifer <gp@suse.com> wrote:
Hi everyone,
today I have some exciting news and a proposal to relay: SUSE wants to go another step in openness towards the openSUSE community and suggests to bring the relationship of openSUSE Leap and SUSE Linux Enterprise to a new level.
Internally this idea is called "Closing the Leap Gap" and proposes to strengthen and bring more closely together:
* developer communities, by focusing on openSUSE Leap as a development platform for communities and industry partners; * user communities, by leveraging the benefits of both a stable Enterprise code base and the speed of community contributions; * the code bases of openSUSE Leap and SUSE Linux Enterprise (SLE), by not only sharing sources, but also offering the SUSE Linux Enterprise binaries for inclusion in openSUSE Leap.
The proposal includes a three step approach:
1. Merge the code bases for the intersection of openSUSE Leap 15.2 and SUSE Linux Enterprise 15 SP2 as much as possible without loss of functionality or stability. (SUSE has started a cleanup process on the SUSE Linux Enterprise side already.) 2. In parallel to classic openSUSE Leap 15.2 create a flavor leveraging SLE binaries, leading to an intermediate release in the October 2020 time frame. 3. Build openSUSE Leap 15.3 with SLE binaries included by default (assuming community agreement).
[...]
So, what do you think?
In principle, I think this is a pretty good idea. I like the idea of bringing SUSE and openSUSE closer together and collaborating better. I've always felt that SUSE was oddly disconnected from the openSUSE community, and I hope this is the start of reintegrating the SUSE business and engineering into the openSUSE community. And yes, I mean it when I say I want the SUSE business involved too. I know many folks don't realize it, but I know that a lot of engineering decisions are led by business folks saying they want or need something. Having the SUSE business folks (most of whom are somewhat to very technically inclined!) involved in development plans and features within the openSUSE community can only help make the SUSE Linux platform an even better one! I still have some questions about how this will play out, but I will wait until the technical proposal is submitted to ask those... -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Am 09.04.20 um 14:20 schrieb Neal Gompa:
In principle, I think this is a pretty good idea. I like the idea of bringing SUSE and openSUSE closer together and collaborating better. I've always felt that SUSE was oddly disconnected from the openSUSE community, and I hope this is the start of reintegrating the SUSE business and engineering into the openSUSE community.
Now if the first step would just be to open all bugzilla entries that are mentioned in openSUSE package change logs... ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Hello Stefan and all, On 2020-04-09 T 15:30 +0200 Stefan Seyfried wrote:
Am 09.04.20 um 14:20 schrieb Neal Gompa:
In principle, I think this is a pretty good idea. I like the idea of bringing SUSE and openSUSE closer together and collaborating better. I've always felt that SUSE was oddly disconnected from the openSUSE community, and I hope this is the start of reintegrating the SUSE business and engineering into the openSUSE community.
Now if the first step would just be to open all bugzilla entries that are mentioned in openSUSE package change logs... ;-)
the need for this and the use case are understood, indeed, and this aspect is on our list to be evaluated in the next months. As you can imagine, though, the devil is in the detail, as in many cases, bugs are filed on behalf of customers or partners, where SUSE needs to protect customer/partner specific information. But you are aware of that challenge anyways, aren't you? Take care and stay healthy! So long - MgE -- Matthias G. Eckermann, Director Product Management Linux Platforms SUSE Software Solutions Germany GmbH - Maxfeldstr. 5 - 90409 Nürnberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Thu, Apr 9, 2020 at 23:35, Matthias G. Eckermann <mge@suse.com> wrote:
the need for this and the use case are understood, indeed, and this aspect is on our list to be evaluated in the next months.
As you can imagine, though, the devil is in the detail, as in many cases, bugs are filed on behalf of customers or partners, where SUSE needs to protect customer/partner specific information.
But you are aware of that challenge anyways, aren't you?
I know of at least one bug that couldn't have been shared with me because it contained some customer info, but had to have been rereported, because it was related to the stuff I do, and had to be assigned to me. That weird bug juggling is how we end up with 3 bug references in one .changes entry, all referring to the same core issue. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Hello, let me play devil's advocate ;-) Am Donnerstag, 9. April 2020, schrieb Matthias G. Eckermann:
On 2020-04-09 T 15:30 +0200 Stefan Seyfried wrote:
Now if the first step would just be to open all bugzilla entries that are mentioned in openSUSE package change logs... ;-)
the need for this and the use case are understood, indeed, and this aspect is on our list to be evaluated in the next months.
SLE bugreports are a topic that is much older than this discussion, even older than Leap. IIRC I already talked to AJ about it at the first (!) openSUSE Conference years ago, and repeated it in more than once, including several (typically face2face) board meetings - basically whenever someone who looked important enough ;-) was there. The answer was always that "the problem is understood, it isn't easy to fix, and it will be evaluated and improved". I'm sorry to say that, but I've heard this long and often enough, and will only believe you once I see lots of public SLE bugreports ;-) The only improvement so far is bugshare - which means sending a mail to ask for details of a specific bugreport, and if you are lucky, you get a reply with a rough (more or less useful) summary of the bugreport. If you are less lucky, the people reading the bugshare requests don't even answer - maybe they are busy with other stuff, maybe for other reasons. (Just wondering - Simon, how many bugshare requests do you/the bugshare team receive per month, and how many of them get answered?) While bugshare is at least an improvement, IMHO it is best described as "nice try". Getting a rough summary of a bugreport isn't too helpful, and the whole bugshare approach doesn't scale well because it involves lots of manual work - someone has to read the bugreport and to write the rough summary. IIRC bugshare was meant as a quick-to-implement workaround until we get the real problem fixed - but I haven't seen progress on the "make (most) SLE bugs public" topic since then. In the meantime, I stopped trying bugshare after getting some not-too- useful summaries and sometimes not always getting an answer at all. Instead, I switched to reading the added patches when seeing a non- public boo/bsc number in a changelog. That's faster (no need to wait/ hope for a bugshare reply) and more helpful - the patch shows what was done, and often allows to understand the underlying bug better than a rough summary of the bugreport. Sadly, this "reverse engeneering" method takes much more time than reading a bugreport, and requires at least some basic knownledge of coding and reading patches.
As you can imagine, though, the devil is in the detail, as in many cases, bugs are filed on behalf of customers or partners, where SUSE needs to protect customer/partner specific information.
But you are aware of that challenge anyways, aren't you?
Yes, I'm aware of these challenges - I've heard about them often enough ;-) OTOH, non-public SLE bugs are a known problem since years (typically becoming more painful before Leap major releases), and quite some people had enough time to think about solutions for these challenges. AFAIK there's a bunch of bugs which get filed by SUSE employees (for example during testing and QA) that don't involve any customer information. Making these bugs public by default shouldn't be too hard. Even worse (and more interesting[tm]) - sometimes Leap bugs get moved to SLE, and at the same time become non-public. To start with - actually making/keeping these bugs public might indeed be a problem. AFAIK the bugzilla config doesn't allow to make SLE bugs public, no matter how hard you try. If this is still true, it should be obvious that this needs to be changed first. (A quick bugzilla report query indicates that there are ~500 public bugs for _Beta_ SLE 15 and SLE 15 SP1, which is not very much [1]. For the final releases, I only found a few bugs - all reported by me, then moved from Leap to SLE and therefore non-public now (I can access them because I'm the reporter). I'll take this as an indication that making SLE bugs public is still not possible.) The bugs with customers or partners involved are indeed the most difficult ones - but even for them, I've heard about methods that would allow to make many of them public. For example, bugzilla allows to mark individual comments as private, so you could have a somewhat generic public bugreport, and then a private comment that includes the customer- specific data. And yes, there might also be some bugs that have to be completely non- public (for example security issues[2] or bugs discussing things that are under NDA). That's completely understandable, and as long as this is only the minority of bugs, it's not a serious problem. I'll end this rant with some proposals how we could get more (most?) SLE bugs public - and some people will notice that there isn't too much new stuff in this list: - change the bugzilla config to make it technically possible to mark SLE bugs as public - when moving a bug from Leap to SLE, keep it public (and/or stop moving bugs from Leap to SLE, see the bonus rant below) - change the bugzilla config so that SLE bugs are public by default - unless the reporter marks them as private. (Of course you'll need to tell that to everybody in advance to avoid unpleasant surprises.) - educate everybody to split bugreports and comments into a) a public generic bugreport/comment, and b) a private comment with customer- specific details so that at least part a) can be public - encourage SLE maintainers to CC the openSUSE maintainers of the affected package in bugreports (AFAIK there are even some AppArmor bugs that I can't access) Oh, and as a somewhat unrelated recommendation: I've heard more than once that moving a bug to SLE helps to get it fixed because "it's important for SLE". While this is a nice trick to convince $manager, I'd recommend to get rid of the need for it, and handle Leap bugs on the same level as SLE bugs ;-) Needless to say that what I wrote above also applies to feature requests in FATE or nowadays Jira. Regards, Christian Boltz [1] ... says someone who - starting with SUSE Linux 9.2 beta - reported a total of 1342 bugs ;-) [2] actually the security team is quite good at making bugs public once the fix is released and the embargo is lifted -- The clean solution would be to kick out the whole freedesktop crap. At least would be nice if freedesktop would only break desktop related stuff instead of whole systems. [Ruediger Meier in opensuse-factory] -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Am 16.04.20 um 00:06 schrieb Christian Boltz:
The answer was always that "the problem is understood, it isn't easy to fix, and it will be evaluated and improved". I'm sorry to say that, but I've heard this long and often enough, and will only believe you once I see lots of public SLE bugreports ;-)
#Metoo
(Just wondering - Simon, how many bugshare requests do you/the bugshare team receive per month)
I'd guess a very low number, because what you get in return is not useful at all (at least for my requests, it was not really useful).
Getting a rough summary of a bugreport isn't too helpful,
Applause for putting this into such nice, friendly words.
IIRC bugshare was meant as a quick-to-implement workaround until we get the real problem fixed - but I haven't seen progress on the "make (most) SLE bugs public" topic since then.
Probably about as much progress as on the "abandon connect.o.o" front ;-)
In the meantime, I stopped trying bugshare after getting some not-too- useful summaries and sometimes not always getting an answer at all. Instead, I switched to reading the added patches when seeing a non- public boo/bsc number in a changelog. That's faster (no need to wait/ hope for a bugshare reply) and more helpful - the patch shows what was done, and often allows to understand the underlying bug better than a rough summary of the bugreport. Sadly, this "reverse engeneering" method takes much more time than reading a bugreport, and requires at least some basic knownledge of coding and reading patches.
I'm doing exactly the same, but pardon me -- this is not worthy of an "open" SUSE operating system.
As you can imagine, though, the devil is in the detail, as in many cases, bugs are filed on behalf of customers or partners, where SUSE needs to protect customer/partner specific information.
But you are aware of that challenge anyways, aren't you?
Yes, I'm aware of these challenges - I've heard about them often enough ;-)
Me too. Heck, I even file as many of our SLES bugs as possible against FACTORY / Leap (often complete with patches and fixes...), just to keep them accessible for everyone. And then they are moved to SLES in the bugfixing process 🤦 This is somewhat insulting...
And yes, there might also be some bugs that have to be completely non- public (for example security issues[2] or bugs discussing things that are under NDA). That's completely understandable, and as long as this is only the minority of bugs, it's not a serious problem.
Fun fact: I have not yet encountered a security bug mentioned in a Leap changelog that was not accessible. The security team is doing their homework very well.
[2] actually the security team is quite good at making bugs public once the fix is released and the embargo is lifted
Aah, should have read the footnotes first ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
participants (20)
-
Aaron Burgemeister -
Adrian Schröter -
Christian Boltz -
cunix -
Gerald Pfeifer -
Jan Engelhardt -
Johannes Kastl -
John Paul Adrian Glaubitz -
Lubos Kocman -
Matthias G. Eckermann -
Matwey V. Kornilov -
Neal Gompa -
Patrick Shanahan -
PGNet Dev -
Richard Brown -
Robert Schweikert -
Simon Lees -
Stasiek Michalski -
Stefan Seyfried -
Wolfgang Rosenauer