And what about Leap 15.5? (was: ALP Communty Meetings have started!)
Dear Geekos, those who joined the openSUSE conference got aware that we have a completely new approach (ALP) on the desk. But until this flies, we need to make sure that Leap stays attractive for the openSUSE community. In other words - Leap 15.5 needs to receive updates and new features - updated versions of Rust and Python, just to mention two burning topics, as both versions shipped as default in current Leap are already EOL. We understand that SLE15-SP5, the basis of Leap 15.5, will be a 'no feature' release. And this is exactly the problem. We need to update the application layer like in the development model before Closing-the-Leap-Gap, ideally from Tumbleweed. In the release engineering meeting on 15.06. [1] this was discussed (briefly). A potential solution could be to collect these updates in a repo like openSUSE:Leap:15.5 The intention of this mail is to get the discussion about a solution started, in order to make Leap 15.5 great product, before ALP flies. - Is a separate repo for application updates a feasible approach? - what needs to be done to set this up? - will submission work 'as before'? - openQA testing? - any other business? Lets get the process started! Cheers Axel [1] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/ thread/AKZ3MH3OPNYQIZEY4ZIXDODTIDNOB6TV/
On Fri, 2022-06-24 at 10:27 +0200, Axel Braun wrote:
Dear Geekos,
those who joined the openSUSE conference got aware that we have a completely new approach (ALP) on the desk.
But until this flies, we need to make sure that Leap stays attractive for the openSUSE community. In other words - Leap 15.5 needs to receive updates and new features - updated versions of Rust and Python, just to mention two burning topics, as both versions shipped as default in current Leap are already EOL.
We understand that SLE15-SP5, the basis of Leap 15.5, will be a 'no feature' release.
And this is exactly the problem. We need to update the application layer like in the development model before Closing-the-Leap-Gap, ideally from Tumbleweed.
In the release engineering meeting on 15.06. [1] this was discussed (briefly). A potential solution could be to collect these updates in a repo like openSUSE:Leap:15.5
The intention of this mail is to get the discussion about a solution started, in order to make Leap 15.5 great product, before ALP flies.
- Is a separate repo for application updates a feasible approach?
Application updates, yes. But core library updates? Probably not - and your examples above of updated versions of Rust and Python would be core library updates. And replacing something used throughout the distribution like Python would require so many other python-dependant applications to be rebuilt, that the result would not be 'Leap', nor be remotely compatable with SLE. And if we don't update Python as the core library but instead have a second Python that needs to be installed alongside. Then I believe we'd need to build and maintain all of our Python modules in addition alongside. I would be surprised if we can find the contributors to do that, I imagine it is a lot of work. and even if we do, anyone consuming that secondary Python would need to modify their software to use that Python and not the system Python. I imagine all the upstreams/maintainers involved would not appreciate that extra work. Especially when that extra work would ultimately be for a lifespan of less than 2 years and would not be relevant/transferable into any future openSUSE ALP development. Regards, Richard
On Fri, Jun 24, 2022 at 10:37:08AM +0200, Richard Brown wrote:
On Fri, 2022-06-24 at 10:27 +0200, Axel Braun wrote:
Dear Geekos,
those who joined the openSUSE conference got aware that we have a completely new approach (ALP) on the desk.
But until this flies, we need to make sure that Leap stays attractive for the openSUSE community. In other words - Leap 15.5 needs to receive updates and new features - updated versions of Rust and Python, just to mention two burning topics, as both versions shipped as default in current Leap are already EOL.
We understand that SLE15-SP5, the basis of Leap 15.5, will be a 'no feature' release.
And this is exactly the problem. We need to update the application layer like in the development model before Closing-the-Leap-Gap, ideally from Tumbleweed.
In the release engineering meeting on 15.06. [1] this was discussed (briefly). A potential solution could be to collect these updates in a repo like openSUSE:Leap:15.5
The intention of this mail is to get the discussion about a solution started, in order to make Leap 15.5 great product, before ALP flies.
- Is a separate repo for application updates a feasible approach?
Application updates, yes.
But core library updates? Probably not - and your examples above of updated versions of Rust and Python would be core library updates.
FWIW rust we deliver via feature updates (started in 15-sp3/15.3). This is not possible with python that easily. Ciao, Marcus
Am Freitag, 24. Juni 2022, 10:37:08 CEST schrieb Richard Brown:
On Fri, 2022-06-24 at 10:27 +0200, Axel Braun wrote:
Dear Geekos,
those who joined the openSUSE conference got aware that we have a completely new approach (ALP) on the desk.
But until this flies, we need to make sure that Leap stays attractive for the openSUSE community. In other words - Leap 15.5 needs to receive updates and new features - updated versions of Rust and Python, just to mention two burning topics, as both versions shipped as default in current Leap are already EOL.
We understand that SLE15-SP5, the basis of Leap 15.5, will be a 'no feature' release.
And this is exactly the problem. We need to update the application layer like in the development model before Closing-the-Leap-Gap, ideally from Tumbleweed.
In the release engineering meeting on 15.06. [1] this was discussed (briefly). A potential solution could be to collect these updates in a repo like openSUSE:Leap:15.5
The intention of this mail is to get the discussion about a solution started, in order to make Leap 15.5 great product, before ALP flies.
- Is a separate repo for application updates a feasible approach?
Application updates, yes.
But core library updates? Probably not - and your examples above of updated versions of Rust and Python would be core library updates.
And replacing something used throughout the distribution like Python would require so many other python-dependant applications to be rebuilt, that the result would not be 'Leap', nor be remotely compatable with SLE.
If you keep doing this with the dead pythons, you won't have to worry about it anymore. Because then there are no current program versions mwhe that still need these ancient things.
And if we don't update Python as the core library but instead have a second Python that needs to be installed alongside. Then I believe we'd need to build and maintain all of our Python modules in addition alongside. I would be surprised if we can find the contributors to do that, I imagine it is a lot of work.
True What always amazes me. They want to introduce things like ALP (that's the docker story, isn't it?), among other things with the justification of the immense effort if you create the packages yourself, as has been the case until now. In contrast, you always ride a dead horse and have to pay for all problems, including security gaps, yourself. Not to mention the additional work that results. This does not fit together. And, sorry, that can come after my experience only from BWLer. Only they come up with such ideas. Regards Eric
On Fri, 2022-06-24 at 11:15 +0200, Eric Schirra wrote:
What always amazes me. They want to introduce things like ALP (that's the docker story, isn't it?),
Docker? Not likely, the current thinking of the Local Container Management WG is that Podman will be the default container runtime for local workloads - with containerd/whatever-is-wanted-by-kubernetes being the non-local, clustered container runtime of choice.
among other things with the justification of the immense effort if you create the packages yourself, as has been the case until now. In contrast, you always ride a dead horse and have to pay for all problems, including security gaps, yourself. Not to mention the additional work that results. This does not fit together. And, sorry, that can come after my experience only from BWLer. Only they come up with such ideas.
Well the obvious bit you seem to be neglecting is, unlike this community-initiated effort by Axel, which will succeed or fail entirely on the backs of volunteers, ALP is initiated by SUSE who are doing so to address very real business needs they seek to address. So, any additional work within the scopes of ALP that SUSE cares about will obviously be something SUSE is willing to invest into. Whether or not that leads to additional work/additional volunteers needed in scopes of ALP that SUSE doesn't care about is another matter..but, by definition, these are areas which SUSE doesnt' care about. Just as you can't force a random contributor-off-the-street to take care of things they dont want to, same should apply to SUSE and ALP. A more nuanced point of course would be to realise that, if ALP delivers on even a minority of it's stated goals, with everything containerised the problems Axel is finding with Leap would no longer apply, because people should be able to mix and match containers from various codestreams.. a new python container atop an old base OS? No problem for the user, and potentially less problem for the maintainers to build and maintain because they can focus on just what they need to get that new python working, not worry about the impact across a huge 15,000+ package codebase. Regards, Richard
Am 2022-06-24 um 12:12 schrieb Richard Brown:
A more nuanced point of course would be to realise that, if ALP delivers on even a minority of it's stated goals, with everything containerised the problems Axel is finding with Leap would no longer apply, because people should be able to mix and match containers from various codestreams..
Yes, but ALP is not planned to be active in SLE/Leap 15, is it? But SLE/Leap 15 still has some time to go, and having e. g. an ancient python base does not help anyone. And as far as I understand this, Axel is considering SLE/Leap 15. * users of SLE 15 (and Leap 15) have to make sure that their locally needed python software is backwards compatible to the old base * maintainers of python packages have to care about the backwards compatibility as well when upstream moves on Wouldn't it be less work if python base was updated to a recent version, since the current versions of python software already support that version? The maintaners have less backporting work to do. Or, as I see with SLE 15.4, there is a Python3 module now parallel to the already existing Python2 module, and it contains a newer base, hooray! Werner --
On Fri, 2022-06-24 at 12:29 +0200, Werner Flamme wrote:
Am 2022-06-24 um 12:12 schrieb Richard Brown:
A more nuanced point of course would be to realise that, if ALP delivers on even a minority of it's stated goals, with everything containerised the problems Axel is finding with Leap would no longer apply, because people should be able to mix and match containers from various codestreams..
Yes, but ALP is not planned to be active in SLE/Leap 15, is it? But SLE/Leap 15 still has some time to go, and having e. g. an ancient python base does not help anyone. And as far as I understand this, Axel is considering SLE/Leap 15.
SLE 15 has a way to go, with a currently advertised end-of-life being 6 years from now (31 July 2028) and an extended LTSS end of life being 3 years after that (31 July 2031) Leap 15 doesn't have nearly as long to go, something like 2.5 years from now dependant on the release of SLE 15 SP5 and ALP As Leap 15.5 is going to be the last Leap, surely you can see the argument that expending extra effort on it would not be as worthwhile as directing that energy to something that will last longer?
* users of SLE 15 (and Leap 15) have to make sure that their locally needed python software is backwards compatible to the old base * maintainers of python packages have to care about the backwards compatibility as well when upstream moves on
Wouldn't it be less work if python base was updated to a recent version, since the current versions of python software already support that version? The maintaners have less backporting work to do. Or, as I see with SLE 15.4, there is a Python3 module now parallel to the already existing Python2 module, and it contains a newer base, hooray!
Users of SLE pay for SLE under the premise that core libraries will not change in any meaningful functional way during the lifespan of the distribution. Something built on the GA version of SLE 15 should continue to work, ideally without recompilation, on all subsequent service packs. I'm sure people will point out exceptions to this premise, and that's fine, businesses don't exactly operate well when adhering to absolutes.. but, given that core premise of SLE 15 I think it's very unlikely you'll see SLE 15 SP5 introducing a new OS python version. Especially when SLE 15 SP5 will not be a feature-heavy release. I could maybe see SUSE coming up with some solutions to that problem for SLE for SLE 15 SP6, but, with the announcement that Leap 15.5 will be the last planned Leap release, there is no suggestion of there ever being a Leap 15.6 based on that SLE 15 SP6.
Hi Geekos, many good points raised in this thread. Let me take one answer to add some thoughts..... Am Freitag, 24. Juni 2022, 12:37:55 CEST schrieb Richard Brown:
On Fri, 2022-06-24 at 12:29 +0200, Werner Flamme wrote:
Am 2022-06-24 um 12:12 schrieb Richard Brown:
A more nuanced point of course would be to realise that, if ALP delivers on even a minority of it's stated goals, with everything containerised the problems Axel is finding with Leap would no longer apply, because people should be able to mix and match containers from various codestreams..
Yes, but ALP is not planned to be active in SLE/Leap 15, is it? But SLE/Leap 15 still has some time to go, and having e. g. an ancient python base does not help anyone. And as far as I understand this, Axel is considering SLE/Leap 15.
Yes, my concern was about Leap 15.5, despite - current state of knowledge - ALP should be the technical basis for the successor of Leap (whatever this will be called).
SLE 15 has a way to go, with a currently advertised end-of-life being 6 years from now (31 July 2028) and an extended LTSS end of life being 3 years after that (31 July 2031)
Yes, and customers pay SUSE for this LTS, and SUSE pays engineers to fix issues. That is not the case for the applications shipped with Leap. There is no volunteer to backport fixes, if an updated version is already available (but does not run on, say python 3.6). The alternative could be to drop the application from Leap 15.4 (and use flatpak with the latest app). To avoid this, we need to update base technology, which then clashes with the SLE basis....rock below, hard place above....
Leap 15 doesn't have nearly as long to go, something like 2.5 years from now dependant on the release of SLE 15 SP5 and ALP
As Leap 15.5 is going to be the last Leap, surely you can see the argument that expending extra effort on it would not be as worthwhile as directing that energy to something that will last longer?
That leads to an even more aggressive approach towards Leap 15.5: Lets drop it completely, extend Leap 15.4 and concentrate on ALP. This has several advantages: - no additional upgrade 15.4 -> 15.5 -> ALP - focus of community resources on maintenance of 15.4 and ALP - in total less effort - to be continued.... When looking at openSUSE in numbers, I'm always surprised how many outdated (10.x, 11, 12, 13, 42, 15.1/2) are still in use. Obviously they run, do what they should, and security seems not to be an issue. I cant say I like this, but its a fact. Proof me wrong, but I feel the community is not eager for a cosmetic update to a system, that contains various base packages that are end-of-lifecycle, and by this cant deliver the applications one wants to use.
* users of SLE 15 (and Leap 15) have to make sure that their locally needed python software is backwards compatible to the old base * maintainers of python packages have to care about the backwards compatibility as well when upstream moves on
Wouldn't it be less work if python base was updated to a recent version, since the current versions of python software already support that version? The maintaners have less backporting work to do. Or, as I see with SLE 15.4, there is a Python3 module now parallel to the already existing Python2 module, and it contains a newer base, hooray!
Users of SLE pay for SLE under the premise that core libraries will not change in any meaningful functional way during the lifespan of the distribution.
Something built on the GA version of SLE 15 should continue to work, ideally without recompilation, on all subsequent service packs.
I'm sure people will point out exceptions to this premise, and that's fine, businesses don't exactly operate well when adhering to absolutes.. but, given that core premise of SLE 15 I think it's very unlikely you'll see SLE 15 SP5 introducing a new OS python version.
Especially when SLE 15 SP5 will not be a feature-heavy release. I could maybe see SUSE coming up with some solutions to that problem for SLE for SLE 15 SP6, but, with the announcement that Leap 15.5 will be the last planned Leap release, there is no suggestion of there ever being a Leap 15.6 based on that SLE 15 SP6.
Probably not. Cheers Axel
On 2022-06-28 13:56, Axel Braun wrote:
Proof me wrong, but I feel the community is not eager for a cosmetic update to a system, that contains various base packages that are end-of-lifecycle, and by this cant deliver the applications one wants to use.
Proving you wrong is somewhat easy We’ve been here before The openSUSE regular release died due to lack of contributions While the numbers of USERS of Leap are very good, the number of CONTRIBUTORS to Leap have not And that is how we ended up in the spot - if Leap had the contributors to do what you want, we’d have done it during Leap 42 and earlier 15 releases Leap was initially intended as a codebase which could be shaped by contributions But, the community failed to contribute, hence SUSE having more and more influence on the Leap codebase, ultimately leading to where we are today. I see no evidence yet of a large contributor base waiting in the wings to prove me wrong Last time we had contributors proving me wrong on a topic like this was the Evergreen LTS effort. They shows up, even if it did also require an addition effort by SUSE (an effort I wouldn’t expect this time). Regardless, Evergreen it ultimately died because Leap solved all the problems for the handful of contributors doing that work.. which leads to the suggestion that an idea like this is really only viable if we’re talking about dozens of contributors willing to commit to doing the work for several years For the record, I am not.
* Richard Brown <rbrown@suse.de> [06-28-22 16:02]:
On 2022-06-28 13:56, Axel Braun wrote:
Proof me wrong, but I feel the community is not eager for a cosmetic update to a system, that contains various base packages that are end-of-lifecycle, and by this cant deliver the applications one wants to use.
Proving you wrong is somewhat easy
We’ve been here before
The openSUSE regular release died due to lack of contributions
While the numbers of USERS of Leap are very good, the number of CONTRIBUTORS to Leap have not
And that is how we ended up in the spot - if Leap had the contributors to do what you want, we’d have done it during Leap 42 and earlier 15 releases
Leap was initially intended as a codebase which could be shaped by contributions
But, the community failed to contribute, hence SUSE having more and more influence on the Leap codebase, ultimately leading to where we are today.
I see no evidence yet of a large contributor base waiting in the wings to prove me wrong
Last time we had contributors proving me wrong on a topic like this was the Evergreen LTS effort.
They shows up, even if it did also require an addition effort by SUSE (an effort I wouldn’t expect this time).
Regardless, Evergreen it ultimately died because Leap solved all the problems for the handful of contributors doing that work.. which leads to the suggestion that an idea like this is really only viable if we’re talking about dozens of contributors willing to commit to doing the work for several years
For the record, I am not.
you are also incorrect about Evergreen as while it is no longer called Evergreen, it very much survives admirably as Tumbleweed. guess contributors have proven you wrong again. -- (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 oftc
On 6/29/22 06:10, Patrick Shanahan wrote:
* Richard Brown <rbrown@suse.de> [06-28-22 16:02]:
On 2022-06-28 13:56, Axel Braun wrote:
Proof me wrong, but I feel the community is not eager for a cosmetic update to a system, that contains various base packages that are end-of-lifecycle, and by this cant deliver the applications one wants to use.
Proving you wrong is somewhat easy
We’ve been here before
The openSUSE regular release died due to lack of contributions
While the numbers of USERS of Leap are very good, the number of CONTRIBUTORS to Leap have not
And that is how we ended up in the spot - if Leap had the contributors to do what you want, we’d have done it during Leap 42 and earlier 15 releases
Leap was initially intended as a codebase which could be shaped by contributions
But, the community failed to contribute, hence SUSE having more and more influence on the Leap codebase, ultimately leading to where we are today.
I see no evidence yet of a large contributor base waiting in the wings to prove me wrong
Last time we had contributors proving me wrong on a topic like this was the Evergreen LTS effort.
They shows up, even if it did also require an addition effort by SUSE (an effort I wouldn’t expect this time).
Regardless, Evergreen it ultimately died because Leap solved all the problems for the handful of contributors doing that work.. which leads to the suggestion that an idea like this is really only viable if we’re talking about dozens of contributors willing to commit to doing the work for several years
For the record, I am not.
you are also incorrect about Evergreen as while it is no longer called Evergreen, it very much survives admirably as Tumbleweed. guess contributors have proven you wrong again.
I'm not sure how you can consider Tumbleweed as a rolling release distro a successor to Evergreen which was about bringing long term support to existing openSUSE releases. In practically every way these to concepts are the opposite of each other the only way they are similar is they both receive significant community contributions -- 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
* Simon Lees <sflees@suse.de> [06-28-22 21:06]:
On 6/29/22 06:10, Patrick Shanahan wrote:
* Richard Brown <rbrown@suse.de> [06-28-22 16:02]:
On 2022-06-28 13:56, Axel Braun wrote:
Proof me wrong, but I feel the community is not eager for a cosmetic update to a system, that contains various base packages that are end-of-lifecycle, and by this cant deliver the applications one wants to use.
Proving you wrong is somewhat easy
We’ve been here before
The openSUSE regular release died due to lack of contributions
While the numbers of USERS of Leap are very good, the number of CONTRIBUTORS to Leap have not
And that is how we ended up in the spot - if Leap had the contributors to do what you want, we’d have done it during Leap 42 and earlier 15 releases
Leap was initially intended as a codebase which could be shaped by contributions
But, the community failed to contribute, hence SUSE having more and more influence on the Leap codebase, ultimately leading to where we are today.
I see no evidence yet of a large contributor base waiting in the wings to prove me wrong
Last time we had contributors proving me wrong on a topic like this was the Evergreen LTS effort.
They shows up, even if it did also require an addition effort by SUSE (an effort I wouldn’t expect this time).
Regardless, Evergreen it ultimately died because Leap solved all the problems for the handful of contributors doing that work.. which leads to the suggestion that an idea like this is really only viable if we’re talking about dozens of contributors willing to commit to doing the work for several years
For the record, I am not.
you are also incorrect about Evergreen as while it is no longer called Evergreen, it very much survives admirably as Tumbleweed. guess contributors have proven you wrong again.
I'm not sure how you can consider Tumbleweed as a rolling release distro a successor to Evergreen which was about bringing long term support to existing openSUSE releases. In practically every way these to concepts are the opposite of each other the only way they are similar is they both receive significant community contributions
I was there and Evergreen was considered a very long term, constantly updated,"rolling" release which morphed into Tumbleweed. and I used Evergreen. tks Greg Kroah-Hartman. -- (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 oftc
On 6/28/2022 20:55, Patrick Shanahan wrote:
I was there and Evergreen was considered a very long term, constantly updated,"rolling" release which morphed into Tumbleweed. and I used Evergreen. tks Greg Kroah-Hartman.
Evergreen was a community-based effort to provide LTS security updates after the EOL for a few consecutive openSUSE releases. It was absolutely not a rolling release. Perhaps you are remembering something besides Evergreen. -- Jason Craig
On Tue, 2022-06-28 at 21:00 -0600, Jason Craig wrote:
On 6/28/2022 20:55, Patrick Shanahan wrote:
I was there and Evergreen was considered a very long term, constantly updated,"rolling" release which morphed into Tumbleweed. and I used Evergreen. tks Greg Kroah-Hartman.
Evergreen was a community-based effort to provide LTS security updates after the EOL for a few consecutive openSUSE releases. It was absolutely not a rolling release. Perhaps you are remembering something besides Evergreen.
It sounds like Patrick is remembering GregKH's original Tumbleweed, which was called Tumbleweed, not Evergreen. I'm rather aware of the difference, given I'm the person who took over the openSUSE:Tumbleweed OBS Project from Greg, and also the one who discussed with Wolfgang (the owner of Evergreen) when Leap was being conceptualised. But I'm open to the possibility of Patrick living in a different reality from me and wish him all the best in his version of this universe.
* Richard Brown <rbrown@suse.de> [06-29-22 03:42]:
On Tue, 2022-06-28 at 21:00 -0600, Jason Craig wrote:
On 6/28/2022 20:55, Patrick Shanahan wrote:
I was there and Evergreen was considered a very long term, constantly updated,"rolling" release which morphed into Tumbleweed. and I used Evergreen. tks Greg Kroah-Hartman.
Evergreen was a community-based effort to provide LTS security updates after the EOL for a few consecutive openSUSE releases. It was absolutely not a rolling release. Perhaps you are remembering something besides Evergreen.
It sounds like Patrick is remembering GregKH's original Tumbleweed, which was called Tumbleweed, not Evergreen.
I'm rather aware of the difference, given I'm the person who took over the openSUSE:Tumbleweed OBS Project from Greg, and also the one who discussed with Wolfgang (the owner of Evergreen) when Leap was being conceptualised.
But I'm open to the possibility of Patrick living in a different reality from me and wish him all the best in his version of this universe.
seems to me that we both possess that reality, and recognizing that poses no problem for me. -- (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 oftc
Richard Brown wrote:
On 2022-06-28 13:56, Axel Braun wrote:
Proof me wrong, but I feel the community is not eager for a cosmetic update to a system, that contains various base packages that are end-of-lifecycle, and by this cant deliver the applications one wants to use. Proving you wrong is somewhat easy We’ve been here before The openSUSE regular release died due to lack of contributions While the numbers of USERS of Leap are very good, the number of CONTRIBUTORS to Leap have not
Are there any numbers you could share with us, in particular compared to TW? Thx. Regards, Frank
On 6/29/22 07:05, Frank Krüger wrote:
Richard Brown wrote:
On 2022-06-28 13:56, Axel Braun wrote:
Proof me wrong, but I feel the community is not eager for a cosmetic update to a system, that contains various base packages that are end-of-lifecycle, and by this cant deliver the applications one wants to use. Proving you wrong is somewhat easy We’ve been here before The openSUSE regular release died due to lack of contributions While the numbers of USERS of Leap are very good, the number of CONTRIBUTORS to Leap have not
Are there any numbers you could share with us, in particular compared to TW? Thx.
Numbers really only provide part of the picture here, because for what Axel is proposing you really need a group of capable people to step up and say we are willing to create and maintain a separate python stack or a separate Qt / KDE. Its relatively easy for a single maintainer to come in and either update or not update a single or group of "leaf" packages and there are contributors doing that for Leap. Whats much harder is there are a number of core packages where SUSE employs someone like myself or a group of people to maintain a set of packages we do this for tumbleweed and SLE, but once you start to change core packages away from what SLE has then you'd have all these other packages that use those that may need attention and you also have to find people to look after those as well so its significant extra work on top of what we have now. -- 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 29/06/2022 08:01, Richard Brown wrote:
On 2022-06-28 13:56, Axel Braun wrote:
Proof me wrong, but I feel the community is not eager for a cosmetic update to a system, that contains various base packages that are end-of-lifecycle, and by this cant deliver the applications one wants to use.
Proving you wrong is somewhat easy
We’ve been here before
The openSUSE regular release died due to lack of contributions
While the numbers of USERS of Leap are very good, the number of CONTRIBUTORS to Leap have not
And that is how we ended up in the spot - if Leap had the contributors to do what you want, we’d have done it during Leap 42 and earlier 15 releases
Leap was initially intended as a codebase which could be shaped by contributions
But, the community failed to contribute, hence SUSE having more and more influence on the Leap codebase, ultimately leading to where we are today.
I see no evidence yet of a large contributor base waiting in the wings to prove me wrong
Last time we had contributors proving me wrong on a topic like this was the Evergreen LTS effort.
They shows up, even if it did also require an addition effort by SUSE (an effort I wouldn’t expect this time).
Regardless, Evergreen it ultimately died because Leap solved all the problems for the handful of contributors doing that work.. which leads to the suggestion that an idea like this is really only viable if we’re talking about dozens of contributors willing to commit to doing the work for several years
For the record, I am not.
What you're saying, then, is that openSUSE is in trouble???? -- Robin K Wellington "Harbour City" New Zealand
On 2022-06-29 01:19, Robin Klitscher wrote:
What you're saying, then, is that openSUSE is in trouble????
Not at all openSUSE is fine Tumbleweed has been the focus of the majority of openSUSE contributors for quite some time now and continues to be the most reliable, most up to date, fastest-to-be-fixed-when-imperfect, Linux distribution known to mankind. MicroOS is even better than regular Tumbleweed What I am saying is that the openSUSE project as a whole has struggled at producing regular releases for a great many years now, and Axels complaints, while valid, are echos of those long unresolved issues. And they are not issues that I wish to help resolve as I’m perfectly happy using MicroOS for everything in my life :)
On 6/28/22 15:01, Richard Brown wrote:
Proving you wrong is somewhat easy
We’ve been here before
The openSUSE regular release died due to lack of contributions
While the numbers of USERS of Leap are very good, the number of CONTRIBUTORS to Leap have not
And that is how we ended up in the spot - if Leap had the contributors to do what you want, we’d have done it during Leap 42 and earlier 15 releases
Leap was initially intended as a codebase which could be shaped by contributions
That seems a bit misleading. After being with SuSE then openSUSE since 7.0 pro, I don't recall and major announcement of this type or any push or request that more contributors were needed, much less what type contribution was being elicited. If the ultimate goal here is to simply nuke Leap to save manhours and just put out SLE in a community version, that has always struct me as somewhat backwards. Prior to the recent openSUSE/SLE realignment, openSUSE served as the lead and bugfix variant of what would settle down and become SLE to ensure paying customers avoided the bugs fixed in openSUSE. And many many community members contributed with QA and bug reports. That has served SuSE well. The aging nature of what comes out in Leap hasn't gone unnoticed. How Leap 15.4 was released with gcc 7.5 (which lacks many five year old C++17 features) was an indication of the problem. Python and other base development packages just makes matters worse. I don't know what the answer is. 15.4 is a damn fine release despite some package being long-in-the-tooth. The Leap model has server openSUSE well. I'd caution against throwing the baby out with the bathwater here. Somehow reasoned minds prevail, and good guidance decisions are made. I have faith that will continue here as well. -- David C. Rankin, J.D.,P.E.
On 6/29/22 09:55, David C. Rankin wrote:
On 6/28/22 15:01, Richard Brown wrote:
Proving you wrong is somewhat easy
We’ve been here before
The openSUSE regular release died due to lack of contributions
While the numbers of USERS of Leap are very good, the number of CONTRIBUTORS to Leap have not
And that is how we ended up in the spot - if Leap had the contributors to do what you want, we’d have done it during Leap 42 and earlier 15 releases
Leap was initially intended as a codebase which could be shaped by contributions
If the ultimate goal here is to simply nuke Leap to save manhours and just put out SLE in a community version, that has always struct me as somewhat backwards. Prior to the recent openSUSE/SLE realignment, openSUSE served as the lead and bugfix variant of what would settle down and become SLE to ensure paying customers avoided the bugs fixed in openSUSE. And many many community members contributed with QA and bug reports. That has served SuSE well.
And it continues to, tumbleweed is currently serving this purpose for ALP and given the closeness in code these days the Leap beta's do an excellent job of this for SLE service packs if any thing Axels proposals start to take us back away from that.
The aging nature of what comes out in Leap hasn't gone unnoticed. How Leap 15.4 was released with gcc 7.5 (which lacks many five year old C++17 features) was an indication of the problem. Python and other base development packages just makes matters worse.
I don't know what the answer is. 15.4 is a damn fine release despite some package being long-in-the-tooth. The Leap model has server openSUSE well. I'd caution against throwing the baby out with the bathwater here.
With unlimited budget and resources the answer would probably be some form of 3rd distro that sits between tumbleweed and Leap, if you had the base for such a distro I imagine it would be more popular with desktop users while the SLE rebuild would probably better for some other users. Unfortunately we don't have limited releases so the compromise we land with is a solid 15.4 release with some older packages which causes issues for some users and probably benefits others and there'd be a group that don't even notice.
Somehow reasoned minds prevail, and good guidance decisions are made. I have faith that will continue here as well.
-- 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 2022-06-29 02:25, David C. Rankin wrote:
On 6/28/22 15:01, Richard Brown wrote:
Proving you wrong is somewhat easy
We’ve been here before
The openSUSE regular release died due to lack of contributions
While the numbers of USERS of Leap are very good, the number of CONTRIBUTORS to Leap have not
And that is how we ended up in the spot - if Leap had the contributors to do what you want, we’d have done it during Leap 42 and earlier 15 releases
Leap was initially intended as a codebase which could be shaped by contribution
That seems a bit misleading. After being with SuSE then openSUSE since 7.0 pro, I don't recall and major announcement of this type or any push or request that more contributors were needed, much less what type contribution was being elicited.
There were multiple announcements stating that regular releases were being delayed and a new release model had to be found Eg. https://www.zdnet.com/article/opensuse-12-2-delayed-again-project-looks-to-r... This effort to reorganise was a multi-year affair which included in person workshops trying to find a route through the problems. I was at one such workshop in my time before joining SUSE as an employee. Later, when I joined SUSE and soon afterwards became Chairman, I was informed that release team had no intention of producing any regular release after 13.2 ie. The openSUSE regular release was dead At the same time, SUSE was trying to come up with ways of encouraging more people to use the SLE codebase. Others, along with myself, effectively co-opted that effort and helped steered it in the direction you now know as Leap I was the one who announced Leap at oSC https://youtu.be/BH99TSrfvq0 I admit, I did not spell out the fact that if the community didn’t accept this idea there would be no other regular releases from openSUSE I made that decision in the hope to avoid a panic But as we’re talking about these things many years later.. yes, openSUSE had problems producing regular releases for years due to lack of contributions. Yes these problems were known, publicly announced, and efforts made to rectify them over years. These efforts failed, and the patience of the remaining regular release builders ran out after 13.2 Leap was thrown in to plug the gap for our users who had not followed our (many and still growing) contributor base to Tumbleweed. Leap was initially designed to be very open to contributions that would diverge from SLE. Few of these contributions came, so Closing the Leap Gap was the result, and Leap is now less open to such contributions. I sympathise for Axels plight but the time for this discussion and effort to address it was back in 2015. I really think Leap (like any conventional regular release) is a lost cause now in 2022.
On 2022/6/28 19:56, Axel Braun wrote:
That is not the case for the applications shipped with Leap. There is no volunteer to backport fixes, if an updated version is already available
To contribute to Tumbleweed it's easy, I just submit a package/patch to OBS and wait for an approval. But I don't really know how to submit/backport a patch to Leap as I really want to submit some patches. There seems to be many procedures I don't know yet.
On 6/29/22 12:33, Fusion Future wrote:
On 2022/6/28 19:56, Axel Braun wrote:
That is not the case for the applications shipped with Leap. There is no volunteer to backport fixes, if an updated version is already available
To contribute to Tumbleweed it's easy, I just submit a package/patch to OBS and wait for an approval. But I don't really know how to submit/backport a patch to Leap as I really want to submit some patches. There seems to be many procedures I don't know yet.
The process for a Leap distro before it is released is much the same its just you submit to a slightly different location. The process for already released leap versions i'll post below, its slightly more complex but at the end of the day pretty similar but its also really designed for adding bugfixes or security fixes rather then new features or version updates. https://en.opensuse.org/openSUSE:Maintenance_update_process -- 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 2022/6/29 12:02, Simon Lees wrote:
The process for a Leap distro before it is released is much the same its just you submit to a slightly different location.
The process for already released leap versions i'll post below, its slightly more complex but at the end of the day pretty similar but its also really designed for adding bugfixes or security fixes rather then new features or version updates.
Thanks. My first submission to Leap has been accepted by following the update process. I can confirm the process is almost the same as Tumbleweed/Factory. https://build.opensuse.org/request/show/985864
On Thu, Jun 30, 2022 at 04:46:18PM +0800, Fusion Future wrote:
On 2022/6/29 12:02, Simon Lees wrote:
The process for a Leap distro before it is released is much the same its just you submit to a slightly different location.
The process for already released leap versions i'll post below, its slightly more complex but at the end of the day pretty similar but its also really designed for adding bugfixes or security fixes rather then new features or version updates.
Thanks. My first submission to Leap has been accepted by following the update process. I can confirm the process is almost the same as Tumbleweed/Factory.
And ... it was incorrect as Fabian pointed out to me. (As the current Leap CtlG process is a buit more complicated when SLES packages are involved.) It should have been gone to SUSE:SLE-15-SP4:Update internally. I am trying to forward your fix to our IBS package repo. Ciao, Marcus
On 2022/6/30 17:00, Marcus Meissner wrote:
It should have been gone to SUSE:SLE-15-SP4:Update internally.
Do you mean if I want to submit patches to packages that are inherited from SLE-15-SP4, I should submit a request to SUSE:SLE-15-SP4:Update (https://build.opensuse.org/project/requests/SUSE:SLE-15-SP4:Update) instead?
On Thu, Jun 30, 2022 at 10:33:41PM +0800, Fusion Future wrote:
On 2022/6/30 17:00, Marcus Meissner wrote:
It should have been gone to SUSE:SLE-15-SP4:Update internally.
Do you mean if I want to submit patches to packages that are inherited from SLE-15-SP4, I should submit a request to SUSE:SLE-15-SP4:Update (https://build.opensuse.org/project/requests/SUSE:SLE-15-SP4:Update) instead?
This would be better, yes. You can find out using osc sm <sourcename> where something comes from. ciao, Marcus
Am Freitag, 24. Juni 2022, 12:12:07 CEST schrieb Richard Brown:
On Fri, 2022-06-24 at 11:15 +0200, Eric Schirra wrote:
Well the obvious bit you seem to be neglecting is, unlike this community-initiated effort by Axel, which will succeed or fail entirely on the backs of volunteers, ALP is initiated by SUSE who are doing so to address very real business needs they seek to address.
So, any additional work within the scopes of ALP that SUSE cares about will obviously be something SUSE is willing to invest into.
Whether or not that leads to additional work/additional volunteers needed in scopes of ALP that SUSE doesn't care about is another matter..but, by definition, these are areas which SUSE doesnt' care about.
Just as you can't force a random contributor-off-the-street to take care of things they dont want to, same should apply to SUSE and ALP.
A more nuanced point of course would be to realise that, if ALP delivers on even a minority of it's stated goals, with everything containerised the problems Axel is finding with Leap would no longer apply, because people should be able to mix and match containers from various codestreams.. a new python container atop an old base OS? No problem for the user, and potentially less problem for the maintainers to build and maintain because they can focus on just what they need to get that new python working, not worry about the impact across a huge 15,000+ package codebase.
Well. Sorry. But I'm absolutely not convinced of the idea with containern, however. In my opinion, one would like to shift the work of package creation (something similar has to be done for container) to the developers themselves, so that one (suse) needs less employees and is not so dependent on the volunteers. Business thinking just. And I don't think that will work. Especially suse will not profit from it. At most, it will work for RedHat, Debian, Ubuntu and Arch. But not with SUSE. If you look at which companies create rpm packages and then look for which distributions, then it is almost never for Suse. Why should that change with container technology? Furthermore, this differs from the philosophy in the direction of Windows. Because even there, each program brings its own libraries. That's one reason why I use linux, because it's not like that there. But if this is now also introduced on Linux via "detours", then I can take the "original" for it. Sorry. In my opinion, maybe I'm wrong, the Linux distributions that rely on conatainerization - and here especially SUSE - are digging their own grave. But let me gladly teach me otherwise. I will follow the project, but will not participate out of conviction. Should it prevail, then I am unfortunately after about 25 years away from Suse. Either with another distri or just again .... Last question. Will Tumbleweed remain as it is, or will the container technology (ALP ) also find its way there? Regards Eric
On 2022-06-24 13:15, Eric Schirra wrote:
And I don't think that will work. Especially suse will not profit from it. At most, it will work for RedHat, Debian, Ubuntu and Arch. But not with SUSE. If you look at which companies create rpm packages and then look for which distributions, then it is almost never for Suse. Why should that change with container technology?
Well it will be different because unlike packages where they need to be built for SUSE to work on SUSE, a distro like ALP that is primarily consuming containers should be able to consume most if not all the containers out there, regardless of which distribution they were built for/on. ALP should therefore have a much larger ecosystem of binaries it can consume outside of those built by SUSE, which is certainly a plus.
Last question. Will Tumbleweed remain as it is, or will the container technology (ALP ) also find its way there?
Tumbleweed is already the originator of many ALP technologies (eg. MicroOS, all official openSUSE containers which use TW as their base). I certainly expect TW to continue to be either ahead or matching ALP as it develops.
Am Freitag, 24. Juni 2022, 15:30:23 CEST schrieb Richard Brown:
On 2022-06-24 13:15, Eric Schirra wrote:
And I don't think that will work. Especially suse will not profit from it. At most, it will work for RedHat, Debian, Ubuntu and Arch. But not with SUSE. If you look at which companies create rpm packages and then look for which distributions, then it is almost never for Suse. Why should that change with container technology?
Well it will be different because unlike packages where they need to be built for SUSE to work on SUSE, a distro like ALP that is primarily consuming containers should be able to consume most if not all the containers out there, regardless of which distribution they were built for/on.
ALP should therefore have a much larger ecosystem of binaries it can consume outside of those built by SUSE, which is certainly a plus.
I myself have not been involved with catainertechnic that much. At most a little bit with docker. And there you can often hear about problems, that a docker package does not work in one or the other distribution. In theory, as always, all seems to work, the praxis then shows a different picture. And the problems do not become less, but shift and partly even more complex. So I can't quite believe your reasoning. As I said, I'm happy to be better informed in the future.
Last question. Will Tumbleweed remain as it is, or will the container technology (ALP ) also find its way there?
Tumbleweed is already the originator of many ALP technologies (eg. MicroOS, all official openSUSE containers which use TW as their base).
I certainly expect TW to continue to be either ahead or matching ALP as it develops.
My question was not aimed at that. I know that Tumbleed is the basis for many other things. My question was about using container technology. In other words. At some point there will be no more normal RPM packages in Leap, to put it bluntly. Then everything possible will be available as containers. Will that be the case in Tumbleweed? Or will that only be a possibility in Tumbleweed? So will I still get all programs as a normal RPM package as before? Regards Eric
On Fri, Jun 24, 2022 at 12:12:07PM +0200, Richard Brown wrote:
On Fri, 2022-06-24 at 11:15 +0200, Eric Schirra wrote:
What always amazes me. They want to introduce things like ALP (that's the docker story, isn't it?),
Docker? Not likely, the current thinking of the Local Container Management WG is that Podman will be the default container runtime for local workloads - with containerd/whatever-is-wanted-by-kubernetes being the non-local, clustered container runtime of choice.
Will the containers be shipped/built with an SBoM (Software Bill Of Materials) from the outset? Lots of organisations are trying to retro-fit or retro-generate SBoMs to help with vulnerability management, compliance etc., it would seem good to bake SBoMs in from the start. A base image with a plethora of container images, from numerous sources is going to ramp-up the management workload to track/react-to potentially vulnerable packages. Daniel
Am Freitag, 24. Juni 2022, 16:09:51 CEST schrieb Daniel Morris:
On Fri, Jun 24, 2022 at 12:12:07PM +0200, Richard Brown wrote:
On Fri, 2022-06-24 at 11:15 +0200, Eric Schirra wrote:
What always amazes me. They want to introduce things like ALP (that's the docker story, isn't it?),
Docker? Not likely, the current thinking of the Local Container Management WG is that Podman will be the default container runtime for local workloads - with containerd/whatever-is-wanted-by-kubernetes being the non-local, clustered container runtime of choice.
Will the containers be shipped/built with an SBoM (Software Bill Of Materials) from the outset? Lots of organisations are trying to retro-fit or retro-generate SBoMs to help with vulnerability management, compliance etc., it would seem good to bake SBoMs in from the start.
A base image with a plethora of container images, from numerous sources is going to ramp-up the management workload to track/react-to potentially vulnerable packages.
THAT. Repeatedly. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech Matrix: @mathias:eregion.de IRC: [Lemmy] on freenode and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On 6/24/22 23:39, Daniel Morris wrote:
On Fri, Jun 24, 2022 at 12:12:07PM +0200, Richard Brown wrote:
On Fri, 2022-06-24 at 11:15 +0200, Eric Schirra wrote:
What always amazes me. They want to introduce things like ALP (that's the docker story, isn't it?),
Docker? Not likely, the current thinking of the Local Container Management WG is that Podman will be the default container runtime for local workloads - with containerd/whatever-is-wanted-by-kubernetes being the non-local, clustered container runtime of choice.
Will the containers be shipped/built with an SBoM (Software Bill Of Materials) from the outset? Lots of organisations are trying to retro-fit or retro-generate SBoMs to help with vulnerability management, compliance etc., it would seem good to bake SBoMs in from the start.
A base image with a plethora of container images, from numerous sources is going to ramp-up the management workload to track/react-to potentially vulnerable packages.
Well from an openSUSE perspective if the base for the vast majority of these packages (atleast for container images we ship) was built from openSUSE / SLE RPM's then this effort might not be significantly more then what we currently do other then things like multiple python versions which will be significantly easier to pull off by having people either use say a python3.8 or python3.10 container environment then it would be to do currently in Leap. -- 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 24/06/2022 10.27, Axel Braun wrote:
Dear Geekos,
those who joined the openSUSE conference got aware that we have a completely new approach (ALP) on the desk.
But until this flies, we need to make sure that Leap stays attractive for the openSUSE community. In other words - Leap 15.5 needs to receive updates and new features - updated versions of Rust and Python, just to mention two burning topics, as both versions shipped as default in current Leap are already EOL.
We understand that SLE15-SP5, the basis of Leap 15.5, will be a 'no feature' release.
And this is exactly the problem. We need to update the application layer like in the development model before Closing-the-Leap-Gap, ideally from Tumbleweed.
In the release engineering meeting on 15.06. [1] this was discussed (briefly). A potential solution could be to collect these updates in a repo like openSUSE:Leap:15.5
The intention of this mail is to get the discussion about a solution started, in order to make Leap 15.5 great product, before ALP flies.
- Is a separate repo for application updates a feasible approach?
IMHO a separate repo would still be feasible and better than nothing. But it would be preferred to base on a SUSE:SLE-15-SP5:GA repository.
- what needs to be done to set this up?
I hope that can be answered by looking into the tasks that have been conducted for Leap 15.4: https://progress.opensuse.org/projects/opensuse-leap-15-4/issues?set_filter=1&status_id=%2A&tracker_id=4
- will submission work 'as before'?
not sure what that means
- openQA testing?
yes. The effort of testing Leap 15.5 if it has only minor differences to Leap 15.4 is very small.
Hi Oliver, Am Dienstag, 28. Juni 2022, 11:20:33 CEST schrieb Oliver Kurz: ....
In the release engineering meeting on 15.06. [1] this was discussed (briefly). A potential solution could be to collect these updates in a repo like openSUSE:Leap:15.5
The intention of this mail is to get the discussion about a solution started, in order to make Leap 15.5 great product, before ALP flies.
- Is a separate repo for application updates a feasible approach?
IMHO a separate repo would still be feasible and better than nothing. But it would be preferred to base on a SUSE:SLE-15-SP5:GA repository.
As development should run in parallel, the latest SUSE:SLE-15-SP5 will probably be the basis....
- what needs to be done to set this up?
I hope that can be answered by looking into the tasks that have been conducted for Leap 15.4: https://progress.opensuse.org/projects/opensuse-leap-15-4/issues?set_filter= 1&status_id=%2A&tracker_id=4
- will submission work 'as before'?
not sure what that means
Submit to openSUSE:Leap:15.5 (instead of finding the right SLE-15-SPx:GA/Update)
- openQA testing?
yes. The effort of testing Leap 15.5 if it has only minor differences to Leap 15.4 is very small.
Good. Cheers Axel
participants (16)
-
Axel Braun -
Axel Braun -
Daniel Morris -
David C. Rankin -
Eric Schirra -
Frank Krüger -
Fusion Future -
Jason Craig -
Marcus Meissner -
Mathias Homann -
Oliver Kurz -
Patrick Shanahan -
Richard Brown -
Robin Klitscher -
Simon Lees -
Werner Flamme