[opensuse-factory] 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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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
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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Apr 09, 2020 at 03:14:50PM +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
None. AFAICT you have dependencies on branding and distribution-logos and whichever package is in the repository provides those. The SLE branding packages will not get imported into the Jump/Leap repository so you will get the Leap branding. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Apr 9, 2020 at 15:22, Michal Suchánek <msuchanek@suse.de> wrote:
On Thu, Apr 09, 2020 at 03:14:50PM +0200, Stasiek Michalski wrote:
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 None.
AFAICT you have dependencies on branding and distribution-logos and whichever package is in the repository provides those. The SLE branding packages will not get imported into the Jump/Leap repository so you will get the Leap branding.
Repositories themselves don't have that power, and currently there are Recommends/Requires in product package and BuildRequires in installation-images to fulfill those branding requirements for various Tumbleweed based flavours (Tumbleweed, MicroOS and Kubic) and Leap. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Donnerstag, 9. April 2020, 15:38:22 CEST wrote Stasiek Michalski:
On Thu, Apr 9, 2020 at 15:22, Michal Suchánek <msuchanek@suse.de> wrote:
On Thu, Apr 09, 2020 at 03:14:50PM +0200, Stasiek Michalski wrote:
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 None.
AFAICT you have dependencies on branding and distribution-logos and whichever package is in the repository provides those. The SLE branding packages will not get imported into the Jump/Leap repository so you will get the Leap branding.
Repositories themselves don't have that power, and currently there are Recommends/Requires in product package and BuildRequires in installation-images to fulfill those branding requirements for various Tumbleweed based flavours (Tumbleweed, MicroOS and Kubic) and Leap.
Right and we will still have an own flavor of them for openSUSE. And if it that is not working consider it as a bug to be resolved... (or it would be indeed a show-stopped for this approach). -- 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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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
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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 14.04.20 at 15:20 Gerald Pfeifer wrote:
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?
We should decide on a sensible name very soon, otherwise Jump will be mentioned in dozens of places already... :-( 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
On 14/04/2020 15.53, Johannes Kastl wrote:
On 14.04.20 at 15:20 Gerald Pfeifer wrote:
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?
We should decide on a sensible name very soon, otherwise Jump will be mentioned in dozens of places already... :-(
I think it is a very bad idea to change names, Yet another Time. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Tue, Apr 14, 2020 at 03:59:49PM +0200, Carlos E. R. wrote:
On 14/04/2020 15.53, Johannes Kastl wrote:
On 14.04.20 at 15:20 Gerald Pfeifer wrote:
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?
We should decide on a sensible name very soon, otherwise Jump will be mentioned in dozens of places already... :-(
I think it is a very bad idea to change names, Yet another Time.
I think this is not to change name, rather to refer to the SLE based Leap while it exists alongside the Leap as it is built now. I don't really see a problem with Jump as a name for such temporary project. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne úterý 14. dubna 2020 16:11:20 CEST, Michal Suchánek napsal(a):
We should decide on a sensible name very soon, otherwise Jump will be mentioned in dozens of places already...
I think it is a very bad idea to change names, Yet another Time.
I think this is not to change name, rather to refer to the SLE based Leap while it exists alongside the Leap as it is built now. I don't really see a problem with Jump as a name for such temporary project.
I don't really see any problem in keeping name Leap during the transition phase. There will be "old" Leap 15.1 and "new" 15.2, won't it? So why not to keep Leap name? It's normal that distributions develop, and they don't have to be necessarily renamed. It'd be more natural to do the transition between 15 and 16, but otherwise I don't really see problem in keeping the name. -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
Em ter., 14 de abr. de 2020 às 11:36, Vojtěch Zeisek <vojtech.zeisek@opensuse.org> escreveu:
Dne úterý 14. dubna 2020 16:11:20 CEST, Michal Suchánek napsal(a):
We should decide on a sensible name very soon, otherwise Jump will be mentioned in dozens of places already...
I think it is a very bad idea to change names, Yet another Time.
I think this is not to change name, rather to refer to the SLE based Leap while it exists alongside the Leap as it is built now. I don't really see a problem with Jump as a name for such temporary project.
I don't really see any problem in keeping name Leap during the transition phase. There will be "old" Leap 15.1 and "new" 15.2, won't it? So why not to keep Leap name? It's normal that distributions develop, and they don't have to be necessarily renamed. It'd be more natural to do the transition between 15 and 16, but otherwise I don't really see problem in keeping the name.
Hi, If I'm not wrong, there will be Leap 15.2 (released in June with openSUSE rpms made from SLE sources) and Leap 15.2 Jump (released in october with SLE rpms) Regards, Luiz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne úterý 14. dubna 2020 16:40:22 CEST, Luiz Fernando Ranghetti napsal(a):
Em ter., 14 de abr. de 2020 às 11:36, Vojtěch Zeisek escreveu:
Dne úterý 14. dubna 2020 16:11:20 CEST, Michal Suchánek napsal(a):
We should decide on a sensible name very soon, otherwise Jump will be mentioned in dozens of places already...
I think it is a very bad idea to change names, Yet another Time.
I think this is not to change name, rather to refer to the SLE based Leap while it exists alongside the Leap as it is built now. I don't really see a problem with Jump as a name for such temporary project.
I don't really see any problem in keeping name Leap during the transition phase. There will be "old" Leap 15.1 and "new" 15.2, won't it? So why not to keep Leap name? It's normal that distributions develop, and they don't have to be necessarily renamed. It'd be more natural to do the transition between 15 and 16, but otherwise I don't really see problem in keeping the name.
If I'm not wrong, there will be Leap 15.2 (released in June with openSUSE rpms made from SLE sources) and Leap 15.2 Jump (released in october with SLE rpms)
If there would be two different Whatever 15.2, it'd be super confusing... -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
Hello team On Tue, 2020-04-14 at 17:43 +0200, Vojtěch Zeisek wrote:
Dne úterý 14. dubna 2020 16:40:22 CEST, Luiz Fernando Ranghetti napsal(a):
Em ter., 14 de abr. de 2020 às 11:36, Vojtěch Zeisek escreveu:
Dne úterý 14. dubna 2020 16:11:20 CEST, Michal Suchánek napsal(a):
We should decide on a sensible name very soon, otherwise Jump will be mentioned in dozens of places already...
I think it is a very bad idea to change names, Yet another Time.
I think this is not to change name, rather to refer to the SLE based Leap while it exists alongside the Leap as it is built now. I don't really see a problem with Jump as a name for such temporary project.
I don't really see any problem in keeping name Leap during the transition phase. There will be "old" Leap 15.1 and "new" 15.2, won't it? So why not to keep Leap name? It's normal that distributions develop, and they don't have to be necessarily renamed. It'd be more natural to do the transition between 15 and 16, but otherwise I don't really see problem in keeping the name.
If I'm not wrong, there will be Leap 15.2 (released in June with openSUSE rpms made from SLE sources) and Leap 15.2 Jump (released in october with SLE rpms)
If there would be two different Whatever 15.2, it'd be super confusing...
We want to test new workflows, maintenance updates etc asap, see if there are some major design flaws. You should really see this just as a having an early protype for the next release priorthe planning phase. Put your hands on it early, because this is how we propose that 15.3 should look like. The More feedback, the better the result. Some people are open to the option that we'd exchange build worklfow in maintenance phase of 15.2. It would not be my preferance, unless protype would work flawlessly and it would be an obvious choice from process/resources point of view. First we really need to know if we'd be even able to do that. That's why the prototype is so important 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
On 4/14/20 5:11 PM, Michal Suchánek wrote:
don't really see a problem with Jump as a name for such temporary project
- excellent name : around here , means *uck ! .... rgds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne úterý 14. dubna 2020 16:11:20 CEST, Michal Suchánek napsal(a):
On Tue, Apr 14, 2020 at 03:59:49PM +0200, Carlos E. R. wrote:
On 14/04/2020 15.53, Johannes Kastl wrote:
On 14.04.20 at 15:20 Gerald Pfeifer wrote:
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?
We should decide on a sensible name very soon, otherwise Jump will be mentioned in dozens of places already... :-(
I think it is a very bad idea to change names, Yet another Time.
I think this is not to change name, rather to refer to the SLE based Leap while it exists alongside the Leap as it is built now. I don't really see a problem with Jump as a name for such temporary project.
If the plan is something like Leap 15.1 -> Leap 15.2 -> Jump 15.2 -> Leap 15.3/16.0 (if I get it correctly), why not rather something like Leap 15.1 -> Leap 15.2 -> Leap 15.2.1 -> Leap 15.3/16.0? -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
On Tue, 2020-04-14 at 17:57 +0200, Vojtěch Zeisek wrote:
Dne úterý 14. dubna 2020 16:11:20 CEST, Michal Suchánek napsal(a):
On Tue, Apr 14, 2020 at 03:59:49PM +0200, Carlos E. R. wrote:
On 14/04/2020 15.53, Johannes Kastl wrote:
On 14.04.20 at 15:20 Gerald Pfeifer wrote:
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?
We should decide on a sensible name very soon, otherwise Jump will be mentioned in dozens of places already... :-(
I think it is a very bad idea to change names, Yet another Time.
I think this is not to change name, rather to refer to the SLE based Leap while it exists alongside the Leap as it is built now. I don't really see a problem with Jump as a name for such temporary project.
If the plan is something like Leap 15.1 -> Leap 15.2 -> Jump 15.2 -> Leap 15.3/16.0 (if I get it correctly), why not rather something like Leap 15.1 -> Leap 15.2 -> Leap 15.2.1 -> Leap 15.3/16.0?
There are two options on the plate. But first let's make sure that it's clear that we will not support two openSUSE Leap based distributions in parallel at least not for primary Arches (RISC-V, armv7 might be different stories). The goal is to reduce effort, not to double it! What's really Jump? Jump is under name "jump" only a tech preview / prototype, which is subject to further research. It's not a supproted upgradable product/project from 15.1 or 15.2. Nobody blocks you to migrate to the tech-preview, we'll be happy for an extra testing, but it's unsupported. In the end we will have to do some heavy testing on all kinds of migrations, as one of goals is seamless migration to SLE. So back to options Option (1) - All goes well (prototype is accepted well, all works as expected). We Start setting up Leap 15.3 Alpha in later summer. openSUSE 15.3 Alpha is already based on the new Jump build workflow. openSUSE 15.2 mainteinance stays untouched. Leap 15.2 is discontinued/unsupported 6 months after 15.3 is releases. Option (2) - Same as (1) + But at some point in time we will rework 15.2 updates to be build in a way like the new openSUSE Leap 15.3 Alpha . openSUSE Leap 15.2 receives a maintenance update which will be released together with install image refresh "aka" intermediate release 15.2.1. I'd really vote for as seamless-as-possible upgrade or even update if possible (let's see how research goes). A lot of packages would be replaced due to vendor changes. This would most likely happen somewhen in Autumn. Perhaps we will really have to use 15.2.1 in case that 15.2 itself would not be upgradable to SLE (again let's see how research goes). But I believe we already claim that user is expected to install all available updates. Option (3) - Everything goes bad, protoype is not accepted well and we keep Leap as it is, but at least we were able to align SLE and Leap sources. Resource-wise (2) is the best option as we can finally focus just at "one" openSUSE Leap build workflow alredy in late Summer/Autumn and save a lot of duplicity on keeping both operational. 12 months is really a lot of time. I'd still like to see Jump operational before we decide to flip the switch. -- 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 Dienstag, 14. April 2020, 17:57:46 CEST wrote Vojtěch Zeisek:
Dne úterý 14. dubna 2020 16:11:20 CEST, Michal Suchánek napsal(a):
On Tue, Apr 14, 2020 at 03:59:49PM +0200, Carlos E. R. wrote:
On 14/04/2020 15.53, Johannes Kastl wrote:
On 14.04.20 at 15:20 Gerald Pfeifer wrote:
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?
We should decide on a sensible name very soon, otherwise Jump will be mentioned in dozens of places already... :-(
I think it is a very bad idea to change names, Yet another Time.
I think this is not to change name, rather to refer to the SLE based Leap while it exists alongside the Leap as it is built now. I don't really see a problem with Jump as a name for such temporary project.
If the plan is something like Leap 15.1 -> Leap 15.2 -> Jump 15.2 -> Leap 15.3/16.0 (if I get it correctly), why not rather something like Leap 15.1 -> Leap 15.2 -> Leap 15.2.1 -> Leap 15.3/16.0?
It is right now not defined what will happen exactly. But we needed another name, because I need to be able to setup it in parallel in OBS. And I must be sure not to break Leap 15.2 with that. So we have therefore openSUSE:Jump:15.2 for now. My only goal there is to get media build (including ftp tree) there atm. So many packages are missing for now. The only thing what is a clear goal for Jump 15.2 is to have a release so that we can also verify maintenance update workflows afterwards. But it is not clear yet if Jump 15.2 will be conidered as experimental release, a parallel official release or even a successor to leap 15.2 This is something what we need to discuss later this year, because I think we all do not have enough insight before. -- 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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 14 Apr 2020, Johannes Kastl wrote:
On 14.04.20 at 15:20 Gerald Pfeifer wrote:
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?
We should decide on a sensible name very soon, otherwise Jump will be mentioned in dozens of places already... :-(
Leap, Jump, Walk, Sleep, Eat ... who cares about names. I like Eat. Anyway, I thought Jump is an intermediate thing alongside Leap 15.2 until it all becomes unified Leap 15.3 again (in case the plan works out and acceptance is there). Richard.
Johannes
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
Hey, On 14.04.20 16:17, Richard Biener wrote:
Anyway, I thought Jump is an intermediate thing alongside Leap 15.2 until it all becomes unified Leap 15.3 again (in case the plan works out and acceptance is there).
It is *sleap*'ing. It's a *sleap*. So to speak... Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2020-04-15 13:29, Henne Vogelsang wrote:
On 14.04.20 16:17, Richard Biener wrote:
Anyway, I thought Jump is an intermediate thing alongside Leap 15.2 until it all becomes unified Leap 15.3 again (in case the plan works out and acceptance is there).
It is *sleap*'ing. It's a *sleap*. So to speak...
SLAPP now! :-D https://www.youtube.com/watch?v=9oHjlpWK3E8 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 14 Apr 2020 15:20:10 +0200, 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
I think this is a great idea from a community perspective - something to bring the community together in a way we haven't seen before. There are some technical challenges (which others far more qualified than me have been discussing at length, from what I can see), but from a community perspective, I see this as a very positive move that has the potential to move us away from "SUSE and non-SUSE" to "us". Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 14 Apr 2020 10:58:54 -0400 Patrick Shanahan wrote:
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. I also think jump is quite good, besides, "leap" and "jump" are identical from /^...p$/i point of view.
Regards, Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2020-04-14 17:04, dieter wrote:
And "LEAP" and "JUMP" are both quite common words.
[...] besides, "leap" and "jump" are identical from /^...p$/i point of view.
And they are part of "leapfrog" and "jumpstyle", but what's the point again? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (19)
-
Adrian Schröter -
Carlos E. R. -
dieter -
ellanios82 -
Gerald Pfeifer -
Henne Vogelsang -
Jan Engelhardt -
Jim Henderson -
Johannes Kastl -
John Paul Adrian Glaubitz -
Lubos Kocman -
Luiz Fernando Ranghetti -
Michal Suchánek -
Neal Gompa -
Patrick Shanahan -
Richard Biener -
Simon Lees -
Stasiek Michalski -
Vojtěch Zeisek