Leap Replacement - Results from recent contributor survey
Hi all, I've been looking at the results from the recent contributor survey to gauge the interest and feasibility of replacing openSUSE Leap with a new community-built offering. For those who may not have been keeping up with the efforts, their are proposals to build two very different distributions to replace Leap: "Linarite" - a regular old fashioned release desktop distribution, likely with a narrower package selection than we're used to with Leap unless we find significantly more contributors to be able to support everything "Slowroll" - a derivative of Tumbleweed, built automatically as much as possible, using automation and metrics to copy packages from Tumbleweed only after certain conditions (max age, X weeks without change, etc). Basically an attempt to provide something less scary than full speed Tumbleweed. Rather than bombard everyone with all the data, I've decided to take the approach of asking specific questions and seeing what data from the survey best helps answer that question. --- Q1: Did the survey reach a representative sample of our contributor base? A: The survey received 251 responses in total, 101 from people who self identified as a 'Contributor', either to the distributions or the Project more broadly. 72 identified as a distribution contributor, which is larger than the 61 people who submitted packages to Leap or Backports for the last release. Therefore I think it's clear the survey reached a broad enough audience to draw some meaningful conclusions from. --- Q2: Between "Linarite", "Slowroll" and not replacing Leap, which is the most popular with our contributors? A: Not replacing Leap was the most popular option when distribution contributors were asked which options would they contribute towards (39%) Not replacing Leap/using Tumbleweed was the most popular option when distribution contributors were asked which would they use on their desktop/laptops (54%) Those same contributors did collectively suggest that Linarite should be the direction of openSUSE (37%) and what they'd use on their servers (43%) Q3. Between "Linarite", "Slowroll" and not replacing Leap, which is the most popular with our users? Slowroll was the most popular option when users were asked which options they'd contribute towards (28%). Linarite was 3rd (19%) after not replacing Leap (25%) Slowroll was also the #1 option when users were asked which option was the best direction for openSUSE (39%) and which would they use on a server (48%). Just using Tumbleweed was also the most popular option with our users for their desktop/laptops (41%), followed by Slowroll (36%) Linarite was not the #1 choice for our users in any of the questions asked. Q4. Do we have enough contributors/Can we get enough contributors to make any option work? 24 distribution contributors said they would contribute to Linarite 13 said they would contribute to Slowroll 49% said they wouldn't contribute to any Leap replacement 26 users said they would contribute to Linarite 38 said they would contribute to Slowroll 53% said they wouldn't contribute to any Leap replacement --- Some thoughts/analysis Our users seem to overwhelmingly favour rolling releases, with 51%-64% expressing a preference for either Tumbleweed or Slowroll regardless of whether they're being asked if they'll use it for Server, Desktop, or whether they'll contribute or think it's the best direction for the project. This preference increases when contributors are asked, with the preference ranging between 55%-71% depending on the question. In the light of these results, it is my suggestion to the community that if we are to build something to replace Leap, then the option we should focus on is Slowroll. It is the most popular with our users, and the option more closely aligned to what our contributors use themselves. I also think its more important for the Leap replacement to focus on Desktop use cases, as openSUSE will also be hosting 1:1 copies of SUSE's ALP products. Those products should be awesome for folk who want Enterprise-like server distros. Given that it seems silly to spread ourselves too thin trying to make a Leap replacement that is both a Server and Desktop OS. That said though, I am still concerned that we do not have enough contributors to make any Leap replacement viable. Leap has struggled even with 61 folk contributing directly to the codebase and backports/PackageHub. And this is when we've had the SLE codebase to borrow from, which dramatically reduced the work required. Either Slowroll or Linarite would require considerably more packaging and maintenance work than Leap. And yet, based on these survey results, we look like we're going to be replacing Leap with significantly _fewer_ contributors than we have even for Leap. Outside of the survey, only 17 people have expressed an interest in working on a Leap replacement, and so far Slowroll and Linarite have both been one-man-shows. Being hopeful, Slowroll does seem to be the concept that promises to convert more users into contributors. And if we focus on Desktop-only (relying on the 1:1 ALP copies for Server) we might not need as much effort. But I worry that we'd do more harm than good for our community to push forward towards any effort that doesn't really have much enthusiasm behind it. The survey clearly shows a tendency for folk to believe openSUSE should do things which they themselves are not willing to contribute to. For a Leap replacement to be viable, both to be made and then supported for years, I'm convinced we need a significant increase in folk rolling up their sleeves and working towards it. So, I want to challenge the community with a few questions Shall we go on with these efforts? If so, are you willing to help? Thoughts, comments, flames all welcome -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
Hi,
The survey clearly shows a tendency for folk to believe openSUSE should do things which they themselves are not willing to contribute to.
My conclusion would have been "to believe openSUSE should not do a slow release at all". As I remember the survey, it did not offer this option at all, so probably people went with some option because they had to choose. For me, the survey shows that the majority thinks Tumbleweed should be the only release model. -nik
On Sat, Sep 02, 2023 at 10:19:54AM +0200, Richard Brown wrote:
Hi all,
I've been looking at the results from the recent contributor survey to gauge the interest and feasibility of replacing openSUSE Leap with a new community-built offering.
For those who may not have been keeping up with the efforts, their are proposals to build two very different distributions to replace Leap:
"Linarite" - a regular old fashioned release desktop distribution, likely with a narrower package selection than we're used to with Leap unless we find significantly more contributors to be able to support everything
"Slowroll" - a derivative of Tumbleweed, built automatically as much as possible, using automation and metrics to copy packages from Tumbleweed only after certain conditions (max age, X weeks without change, etc). Basically an attempt to provide something less scary than full speed Tumbleweed.
Rather than bombard everyone with all the data, I've decided to take the approach of asking specific questions and seeing what data from the survey best helps answer that question.
--- Q1: Did the survey reach a representative sample of our contributor base?
A: The survey received 251 responses in total, 101 from people who self identified as a 'Contributor', either to the distributions or the Project more broadly. 72 identified as a distribution contributor, which is larger than the 61 people who submitted packages to Leap or Backports for the last release. Therefore I think it's clear the survey reached a broad enough audience to draw some meaningful conclusions from.
--- Q2: Between "Linarite", "Slowroll" and not replacing Leap, which is the most popular with our contributors?
A: Not replacing Leap was the most popular option when distribution contributors were asked which options would they contribute towards (39%)
Not replacing Leap/using Tumbleweed was the most popular option when distribution contributors were asked which would they use on their desktop/laptops (54%)
Those same contributors did collectively suggest that Linarite should be the direction of openSUSE (37%) and what they'd use on their servers (43%)
Q3. Between "Linarite", "Slowroll" and not replacing Leap, which is the most popular with our users?
Slowroll was the most popular option when users were asked which options they'd contribute towards (28%). Linarite was 3rd (19%) after not replacing Leap (25%)
Slowroll was also the #1 option when users were asked which option was the best direction for openSUSE (39%) and which would they use on a server (48%).
Just using Tumbleweed was also the most popular option with our users for their desktop/laptops (41%), followed by Slowroll (36%)
Linarite was not the #1 choice for our users in any of the questions asked.
Q4. Do we have enough contributors/Can we get enough contributors to make any option work?
24 distribution contributors said they would contribute to Linarite 13 said they would contribute to Slowroll 49% said they wouldn't contribute to any Leap replacement
26 users said they would contribute to Linarite 38 said they would contribute to Slowroll 53% said they wouldn't contribute to any Leap replacement
--- Some thoughts/analysis
Our users seem to overwhelmingly favour rolling releases, with 51%-64% expressing a preference for either Tumbleweed or Slowroll regardless of whether they're being asked if they'll use it for Server, Desktop, or whether they'll contribute or think it's the best direction for the project.
This preference increases when contributors are asked, with the preference ranging between 55%-71% depending on the question.
In the light of these results, it is my suggestion to the community that if we are to build something to replace Leap, then the option we should focus on is Slowroll.
It is the most popular with our users, and the option more closely aligned to what our contributors use themselves.
I also think its more important for the Leap replacement to focus on Desktop use cases, as openSUSE will also be hosting 1:1 copies of SUSE's ALP products. Those products should be awesome for folk who want Enterprise-like server distros.
Given that it seems silly to spread ourselves too thin trying to make a Leap replacement that is both a Server and Desktop OS.
That said though, I am still concerned that we do not have enough contributors to make any Leap replacement viable.
Leap has struggled even with 61 folk contributing directly to the codebase and backports/PackageHub. And this is when we've had the SLE codebase to borrow from, which dramatically reduced the work required.
Either Slowroll or Linarite would require considerably more packaging and maintenance work than Leap.
Hello, why do you think that Slowroll would require more packaging effort than Leap? Just as Leap derives from SLE, Slowroll derives from Tumbleweed. I could even argue that Slowroll would require less effort when all packages come from Tumbleweed while Leap is built on top of SLE and has a large number of packages of its own. Thanks Michal
On Sat, 2023-09-02 at 10:43 +0200, Michal Suchánek wrote:
Hello,
why do you think that Slowroll would require more packaging effort than Leap?
Just as Leap derives from SLE, Slowroll derives from Tumbleweed.
I could even argue that Slowroll would require less effort when all packages come from Tumbleweed while Leap is built on top of SLE and has a large number of packages of its own.
Because, unlike Leap where maintenance for SLE packages is effectively 'automatic' (ie. taken care as part of the daily business of SLE), and unlike Tumbleweed where it's also effectively 'automatic' ('just throw a new version at it), Slowroll will likely require old-fashioned maintenance (CVE bumps, backports, narrow-fixes) for packages in Slowroll but not-yet-ready to be copied from Tumbleweed I suppose we COULD just take the approach of having Slowroll carrying 'known issues' until the impacted packages pull from Tumbleweed But I think that's not exactly an ethical way of distributing software - if that's the route we go down, we'd need to make it very clear that Tumbleweed would be the objectively more secure, better maintained offering of the Project. And if that becomes the case, then what would the point of Slowroll be? So yeah, if we're going to do Slowroll, we need to maintain is well, which would mean rapid response for narrow fixes when bugs/CVE's/security issues arise but we can't trust the packages from Tumbleweed yet to resolve them. And I recognise that's an extra challenge to find contributors willing to do that work given, under a model like Slowroll, we absolutely will be throwing away that work and replacing it with packages from Tumbleweed within a designated time. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
On Sat, Sep 02, 2023 at 10:49:51AM +0200, Richard Brown wrote:
On Sat, 2023-09-02 at 10:43 +0200, Michal Suchánek wrote:
Hello,
why do you think that Slowroll would require more packaging effort than Leap?
Just as Leap derives from SLE, Slowroll derives from Tumbleweed.
I could even argue that Slowroll would require less effort when all packages come from Tumbleweed while Leap is built on top of SLE and has a large number of packages of its own.
Because, unlike Leap where maintenance for SLE packages is effectively 'automatic' (ie. taken care as part of the daily business of SLE), and unlike Tumbleweed where it's also effectively 'automatic' ('just throw a new version at it), Slowroll will likely require old-fashioned maintenance (CVE bumps, backports, narrow-fixes) for packages in Slowroll but not-yet-ready to be copied from Tumbleweed
It depends on the criteria for 'ready' and the distance between Slowroll and Tumbleweed. If a new version of a library fixes a CVE and does not look problematic otherwise it can be just declared 'ready' - there is about as much risk of breakage from upgrading as there is from backporting a fix. Then there are times when it's more problematic - upgrading to a new KDE version to fix a CVE is somewhat dodgy. Thanks Michal
On 2023-09-02 11:15, Michal Suchánek wrote:
On Sat, Sep 02, 2023 at 10:49:51AM +0200, Richard Brown wrote:
Because, unlike Leap where maintenance for SLE packages is effectively 'automatic' (ie. taken care as part of the daily business of SLE), and unlike Tumbleweed where it's also effectively 'automatic' ('just throw a new version at it), Slowroll will likely require old-fashioned maintenance (CVE bumps, backports, narrow-fixes) for packages in Slowroll but not-yet-ready to be copied from Tumbleweed
It depends on the criteria for 'ready' and the distance between Slowroll and Tumbleweed.
If a new version of a library fixes a CVE and does not look problematic otherwise it can be just declared 'ready' - there is about as much risk of breakage from upgrading as there is from backporting a fix.
Then there are times when it's more problematic - upgrading to a new KDE version to fix a CVE is somewhat dodgy.
Yup, agreed. And that’s some work that will need to be done, assessing, deciding upon and coordinating such maintenance. And that work is more than was required for Leap. And considering Leap had one sole lonely Marcus, as awesome as he is, I don’t think he’d scale well in this new world of Slowroll, hence, we’d need more folk. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
et al: Just responding over here, as someone who did take the survey . . . as always the questions steer the taker in certain predetermined directions . . . which then lead to conclusions. As an older GUI user of various linux distros I "like" Leap, for a "stable" release option in the openSUSE paradigm. I don't recall if there was a question on "keep Leap going as it is???" but I would have clicked that option . . . . I think the questions were, "If you came to a fork in the road, would you choose 'linarite' or would you choose 'slowroll'?" In that choice I said "slowroll" which would be more like Manjaro, where a small number of packages gets upgraded every few weeks . . . which would be closer to what Leap has been. I do "like" "fresh horsies" in my OSs . . . newer kernels seem to be faster handling . . . but, at times the "total and complete rebuild of every nook and cranny" of TW does require more processor time, and that is where Leap offers "systematic stability" that for many end users is a good choice for a daily driver. I think there are a fair number of openSUSE users who would opt for the stable release offering of Leap. And that follows the Debian model of providing, "unstable," "testing," and finally "stable" release offerings, to provide different user needs with something close to their style.
On Sat, 2 Sep 2023 10:20:46 -0500 Larry Len Rainey wrote:
I think the easy way to "slow roll" would be like this.
Tumbleweed - would stay the same.
Leap would be "last weeks stable Tumbleweed" except for kernel CVE's they would go out ASAP. Any Bugzilla confirms would go into a grep -v list to be done in to prevent them from updating.
My thoughts with the given choices of "slow roll" and the rest was just to use tumbleweed-cli and to use "known good" snapshots. The "known good" is the tricky part. Maybe something like - solves bugs and security issues (from the snapshot announcement, problematic for this is that the announcement only contains the packages from the DVD), - does not introduce serious new issues. For this it would be helpful to know the number of downloads of a snapshot and the bugs opened for the snapshot. And the openQA results of course. Kind regards, Dieter
On Sat Sep 2, 2023 at 10:19 AM CEST, Richard Brown wrote:
I also think its more important for the Leap replacement to focus on Desktop use cases, as openSUSE will also be hosting 1:1 copies of SUSE's ALP products. Those products should be awesome for folk who want Enterprise-like server distros.
Wouldn’t no-support-free-as-in-beer-ALP (whether such thing will exist is another question) be effectivelly Slowroll maintained without the community effort? Best, Matěj -- https://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 La vita è una combinazione di magia e pasta. -- Federico Fellini
On 2023-09-02 12:22, Matěj Cepl wrote:
On Sat Sep 2, 2023 at 10:19 AM CEST, Richard Brown wrote:
I also think its more important for the Leap replacement to focus on Desktop use cases, as openSUSE will also be hosting 1:1 copies of SUSE's ALP products. Those products should be awesome for folk who want Enterprise-like server distros.
Wouldn’t no-support-free-as-in-beer-ALP (whether such thing will exist is another question) be effectivelly Slowroll maintained without the community effort?
I don’t think so The lifecycle of various ALP products has not yet been locked down, but there’s some assumptions we can consider as highly likely - different ALP products will have different lifecycles (eg like we already see with SLE Micro moving faster than SLE) - some ALP products may move in a rolling fashion, some may not - even the fastest most rolling ALP products are likely to be slower than where I expect Slowroll to end up If we do Slowroll I think the benefit to the community will be the ability to set a pace that suits the community and only the community. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
On Sat Sep 2, 2023 at 1:32 PM CEST, Richard Brown wrote:
Wouldn’t no-support-free-as-in-beer-ALP (whether such thing will exist is another question) be effectivelly Slowroll maintained without the community effort?
I don’t think so
The lifecycle of various ALP products has not yet been locked down, but there’s some assumptions we can consider as highly likely
1. Of course, when I said “ALP” I meant “one of products based on ALP”. 2. In the end I have replied on Reddit: Aren’t all MicroOS versions derived from Tumbleweed? Then the one thing they are missing is slowness. You wouldn’t believe how normal people (like my wife or my mother) whine when they get upgrades all the time. Most people have better things to do with their computers than to play with them (or develop with them) and they are usually really not interested in keeping their system up to the latest whims of developers. And yes, the idea of micro-host-system with flatpaks is a good one. Just make that host system slower to update (flatpaks are already too fast). Something like openSUSE/SLE Micro-based Leap? Best, Matěj -- https://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Las cosas claras y el chocolate espeso. (Ideas should be clear and chocolate thick.) -- Spanish proverb
On 2023-09-02 04:19, Richard Brown wrote:
The survey clearly shows a tendency for folk to believe openSUSE should do things which they themselves are not willing to contribute to.
Speaking for myself, it is not "will", but being unable to. You could consider some kind of training sessions or tutoring on how to contribute on OBS for dumbs. (I find OBS terribly obscure and difficult) -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On Sat, Sep 2, 2023 at 11:47 AM, Carlos E. R. <[robin.listas@gmx.es](mailto:On Sat, Sep 2, 2023 at 11:47 AM, Carlos E. R. <<a href=)> wrote:
On 2023-09-02 04:19, Richard Brown wrote:
The survey clearly shows a tendency for folk to believe openSUSE should do things which they themselves are not willing to contribute to.
Speaking for myself, it is not "will", but being unable to.
You could consider some kind of training sessions or tutoring on how to contribute on OBS for dumbs.
(I find OBS terribly obscure and difficult)
-- Cheers / Saludos,
Carlos E. R.
(from openSUSE 15.5 (Laicolasse))
Hi - Have you tried this link? https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory
On 2023-09-02 11:58, John Kizer via openSUSE Factory wrote:
On Sat, Sep 2, 2023 at 11:47 AM, Carlos E. R. <...> wrote:
On 2023-09-02 04:19, Richard Brown wrote:
The survey clearly shows a tendency for folk to believe openSUSE should do things which they themselves are not willing to contribute to.
Speaking for myself, it is not "will", but being unable to.
You could consider some kind of training sessions or tutoring on how to contribute on OBS for dumbs.
(I find OBS terribly obscure and difficult)
Hi - Have you tried this link?
https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory <https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory>
That's a far cry from "OBS for dummies" training sessions :-) And I would not contribute to Factory, that's way too fast. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On Sat 02 Sep 2023 12:12:24 PM CDT, Carlos E. R. wrote:
On 2023-09-02 11:58, John Kizer via openSUSE Factory wrote:
On Sat, Sep 2, 2023 at 11:47 AM, Carlos E. R. <...> wrote:
On 2023-09-02 04:19, Richard Brown wrote:
The survey clearly shows a tendency for folk to believe openSUSE should do things which they themselves are not willing to contribute to.
Speaking for myself, it is not "will", but being unable to.
You could consider some kind of training sessions or tutoring on how to contribute on OBS for dumbs.
(I find OBS terribly obscure and difficult)
Hi - Have you tried this link?
https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory <https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory>
That's a far cry from "OBS for dummies" training sessions :-)
And I would not contribute to Factory, that's way too fast.
Hi Carlos Factory can be as fast or slow as you, the maintainer want it to be ;) Anyway, do you use Slack? Or IRC #opensuse-packaging? You can always ask questions at the above.... happy to help if I can. -- Cheers Malcolm °¿° (Linux Counter #276890) Tumbleweed 20230828 | GNOME Shell 44.3 | 6.4.11-1-default HP Z440 | Xeon E5-2695 V4 X36 @ 2.10GHz | Quadro T400/Tesla P4 up 3 days 15:59, 3 users, load average: 0.16, 0.15, 0.10
On Sat, Sep 2, 2023 at 12:12 PM Carlos E. R. <robin.listas@gmx.es> wrote:
On 2023-09-02 11:58, John Kizer via openSUSE Factory wrote:
On Sat, Sep 2, 2023 at 11:47 AM, Carlos E. R. <...> wrote:
On 2023-09-02 04:19, Richard Brown wrote:
The survey clearly shows a tendency for folk to believe openSUSE should do things which they themselves are not willing to contribute to.
Speaking for myself, it is not "will", but being unable to.
You could consider some kind of training sessions or tutoring on how to contribute on OBS for dumbs.
(I find OBS terribly obscure and difficult)
Hi - Have you tried this link?
https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory <https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory>
That's a far cry from "OBS for dummies" training sessions :-)
And I would not contribute to Factory, that's way too fast.
-- Cheers / Saludos,
Carlos E. R.
(from openSUSE 15.5 (Laicolasse))
-- Terror PUP a.k.a Chuck "PUP" Payne ----------------------------------------- Discover it! Enjoy it! Share it! openSUSE Linux. ----------------------------------------- openSUSE -- Terrorpup openSUSE Ambassador/openSUSE Member skype,twiiter,identica,friendfeed -- terrorpup freenode(irc) --terrorpup/lupinstein Register Linux Userid: 155363 So, I know my opinion won't matter, but this why I been wondering moving away from Leap to ALP, It didn't make sense. Leap is great, now with Red Hat cut offline access, there needs to be an Enterprise version of Linux. Ubuntu will never be that, openSUSE Leap is it, now is the time for us to move back in. I can see why many move to Ubuntu, openSUSE packages have growning less. Why did I move from Red Hat in the late 90's to SuSE, PACKAGES!!! No offence, have you play with RHEL 9.0, they have less that us. It's like IBM wants to kill RH. So, more packages would be a plus. Stable to keep the enterprise level would be great. Sorry to rag on ALP, no ever explained it well, and still like another version of MicroOS, and when you try to ask they got very defensive. So I stopped acting. Tumbleweed is great for those that want to help test and make sure the next very of LEAP is going to be great. So keep just Leap Tumbleweed MicroOS So try to create things people don't want. Focus on add thing to what we have to make them great again. openSUSE Community Member since 2008.
------- Original Message ------- On Saturday, September 2nd, 2023 at 12:59 PM, Chuck Payne <terrorpup@gmail.com> wrote:
On Sat, Sep 2, 2023 at 12:12 PM Carlos E. R. <robin.listas@gmx.es> wrote:
On 2023-09-02 11:58, John Kizer via openSUSE Factory wrote:
On Sat, Sep 2, 2023 at 11:47 AM, Carlos E. R. <...> wrote:
On 2023-09-02 04:19, Richard Brown wrote:
The survey clearly shows a tendency for folk to believe openSUSE should do things which they themselves are not willing to contribute to.
Speaking for myself, it is not "will", but being unable to.
You could consider some kind of training sessions or tutoring on how to contribute on OBS for dumbs.
(I find OBS terribly obscure and difficult)
Hi - Have you tried this link?
https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory <https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory>
That's a far cry from "OBS for dummies" training sessions :-)
And I would not contribute to Factory, that's way too fast.
-- Cheers / Saludos,
Carlos E. R.
(from openSUSE 15.5 (Laicolasse))
--
Terror PUP a.k.a Chuck "PUP" Payne ----------------------------------------- Discover it! Enjoy it! Share it! openSUSE Linux. ----------------------------------------- openSUSE -- Terrorpup openSUSE Ambassador/openSUSE Member skype,twiiter,identica,friendfeed -- terrorpup freenode(irc) --terrorpup/lupinstein Register Linux Userid: 155363
So, I know my opinion won't matter, but this why I been wondering moving away from Leap to ALP, It didn't make sense.
Leap is great, now with Red Hat cut offline access, there needs to be an Enterprise version of Linux. Ubuntu will never be that, openSUSE Leap is it, now is the time for us to move back in. I can see why many move to Ubuntu, openSUSE packages have growning less. Why did I move from Red Hat in the late 90's to SuSE, PACKAGES!!! No offence, have you play with RHEL 9.0, they have less that us. It's like IBM wants to kill RH. So, more packages would be a plus. Stable to keep the enterprise level would be great.
Sorry to rag on ALP, no ever explained it well, and still like another version of MicroOS, and when you try to ask they got very defensive. So I stopped acting.
Tumbleweed is great for those that want to help test and make sure the next very of LEAP is going to be great.
So keep just
Leap Tumbleweed MicroOS
So try to create things people don't want. Focus on add thing to what we have to make them great again.
openSUSE Community Member since 2008.
Just to clarify, you mention that there needs to be an Enterprise version of Linux. That is SUSE's job, is it not? Their current product is SLE and the umpteen variations they produce, their future product is <things based off of> ALP. openSUSE's "job" is to be a community-built, community-used Linux distro, right? (I don't see much of an overlap between anywhere RHEL would be used and anywhere openSUSE products would be used?) So it's whatever the community wants it to be, ideally using the unique strengths that the openSUSE project possesses. As I see it, those unique strengths are 1) the Tumbleweed production model, including openQA and 2) access to the exact 1:1 enterprise product from SUSE, so a product can be put together for similar-to-enterprise use cases. It would seem - to me intuitively, and based on the survey results to at least a plurality of others - that the most common "community" need would be for up-to-date software in a coherent package, plain and simple. That's Tumbleweed. If you want "a distro similar to what SUSE produces for enterprise", that will still be around, although likely with less desktop/end-user-oriented software available than what was in SLE/Leap since enterprises presumably don't actually want to pay that much for such software to exist on Linux desktops. If you want a point release model, end-user-oriented, non-enterprise distro that is still based on the SUSE enterprise code base...it seems like the option would be to rally together a group of folks to produce and maintain that - knowing that it will include not just initial production, but the years upon years of work required to monitor thousands of upstream packages and pick, choose and implement downstream patches to keep the whole distribution at some level of security/operability. Sorry if this is irrelevant / inaccurate / unhelpful, but from a relative outsider's perspective it seems like there is still some confusion that could be cleared up?
On Sat, Sep 2, 2023 at 2:13 PM John Kizer via openSUSE Factory < factory@lists.opensuse.org> wrote:
------- Original Message ------- On Saturday, September 2nd, 2023 at 12:59 PM, Chuck Payne < terrorpup@gmail.com> wrote:
On Sat, Sep 2, 2023 at 12:12 PM Carlos E. R. <robin.listas@gmx.es> wrote:
On 2023-09-02 11:58, John Kizer via openSUSE Factory wrote:
On Sat, Sep 2, 2023 at 11:47 AM, Carlos E. R. <...> wrote:
On 2023-09-02 04:19, Richard Brown wrote:
The survey clearly shows a tendency for folk to believe openSUSE should do things which they themselves are not willing to contribute to.
Speaking for myself, it is not "will", but being unable to.
You could consider some kind of training sessions or tutoring on how to contribute on OBS for dumbs.
(I find OBS terribly obscure and difficult)
Hi - Have you tried this link?
https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory <https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory>
That's a far cry from "OBS for dummies" training sessions :-)
And I would not contribute to Factory, that's way too fast.
-- Cheers / Saludos,
Carlos E. R.
(from openSUSE 15.5 (Laicolasse))
-- Terror PUP a.k.a Chuck "PUP" Payne ----------------------------------------- Discover it! Enjoy it! Share it! openSUSE Linux. ----------------------------------------- openSUSE -- Terrorpup openSUSE Ambassador/openSUSE Member skype,twiiter,identica,friendfeed -- terrorpup freenode(irc) --terrorpup/lupinstein Register Linux Userid: 155363
So, I know my opinion won't matter, but this why I been wondering moving away from Leap to ALP, It didn't make sense.
Leap is great, now with Red Hat cut offline access, there needs to be an Enterprise version of Linux. Ubuntu will never be that, openSUSE Leap is it, now is the time for us to move back in. I can see why many move to Ubuntu, openSUSE packages have growning less. Why did I move from Red Hat in the late 90's to SuSE, PACKAGES!!! No offence, have you play with RHEL 9.0, they have less that us. It's like IBM wants to kill RH. So, more packages would be a plus. Stable to keep the enterprise level would be great.
Sorry to rag on ALP, no ever explained it well, and still like another version of MicroOS, and when you try to ask they got very defensive. So I stopped acting.
Tumbleweed is great for those that want to help test and make sure the next very of LEAP is going to be great.
So keep just
Leap Tumbleweed MicroOS
So try to create things people don't want. Focus on add thing to what we have to make them great again.
openSUSE Community Member since 2008.
Just to clarify, you mention that there needs to be an Enterprise version of Linux. That is SUSE's job, is it not? Their current product is SLE and the umpteen variations they produce, their future product is <things based off of> ALP.
openSUSE's "job" is to be a community-built, community-used Linux distro, right? (I don't see much of an overlap between anywhere RHEL would be used and anywhere openSUSE products would be used?) So it's whatever the community wants it to be, ideally using the unique strengths that the openSUSE project possesses. As I see it, those unique strengths are 1) the Tumbleweed production model, including openQA and 2) access to the exact 1:1 enterprise product from SUSE, so a product can be put together for similar-to-enterprise use cases.
It would seem - to me intuitively, and based on the survey results to at least a plurality of others - that the most common "community" need would be for up-to-date software in a coherent package, plain and simple. That's Tumbleweed. If you want "a distro similar to what SUSE produces for enterprise", that will still be around, although likely with less desktop/end-user-oriented software available than what was in SLE/Leap since enterprises presumably don't actually want to pay that much for such software to exist on Linux desktops.
If you want a point release model, end-user-oriented, non-enterprise distro that is still based on the SUSE enterprise code base...it seems like the option would be to rally together a group of folks to produce and maintain that - knowing that it will include not just initial production, but the years upon years of work required to monitor thousands of upstream packages and pick, choose and implement downstream patches to keep the whole distribution at some level of security/operability.
Sorry if this is irrelevant / inaccurate / unhelpful, but from a relative outsider's perspective it seems like there is still some confusion that could be cleared up?
CentOS was that, RH killed it. That what I mean, we could step up to fill that void. -- Terror PUP a.k.a Chuck "PUP" Payne ----------------------------------------- Discover it! Enjoy it! Share it! openSUSE Linux. ----------------------------------------- openSUSE -- Terrorpup openSUSE Ambassador/openSUSE Member skype,twiiter,identica,friendfeed -- terrorpup freenode(irc) --terrorpup/lupinstein Register Linux Userid: 155363 openSUSE Community Member since 2008.
On 9/2/23 17:49, Richard Brown wrote:
Hi all,
I've been looking at the results from the recent contributor survey to gauge the interest and feasibility of replacing openSUSE Leap with a new community-built offering.
For those who may not have been keeping up with the efforts, their are proposals to build two very different distributions to replace Leap:
"Linarite" - a regular old fashioned release desktop distribution, likely with a narrower package selection than we're used to with Leap unless we find significantly more contributors to be able to support everything
"Slowroll" - a derivative of Tumbleweed, built automatically as much as possible, using automation and metrics to copy packages from Tumbleweed only after certain conditions (max age, X weeks without change, etc). Basically an attempt to provide something less scary than full speed Tumbleweed.
Rather than bombard everyone with all the data, I've decided to take the approach of asking specific questions and seeing what data from the survey best helps answer that question.
--- Some thoughts/analysis
Our users seem to overwhelmingly favour rolling releases, with 51%-64% expressing a preference for either Tumbleweed or Slowroll regardless of whether they're being asked if they'll use it for Server, Desktop, or whether they'll contribute or think it's the best direction for the project.
This preference increases when contributors are asked, with the preference ranging between 55%-71% depending on the question.
In the light of these results, it is my suggestion to the community that if we are to build something to replace Leap, then the option we should focus on is Slowroll.
It is the most popular with our users, and the option more closely aligned to what our contributors use themselves.
I also think its more important for the Leap replacement to focus on Desktop use cases, as openSUSE will also be hosting 1:1 copies of SUSE's ALP products. Those products should be awesome for folk who want Enterprise-like server distros.
Given that it seems silly to spread ourselves too thin trying to make a Leap replacement that is both a Server and Desktop OS.
That said though, I am still concerned that we do not have enough contributors to make any Leap replacement viable.
Leap has struggled even with 61 folk contributing directly to the codebase and backports/PackageHub. And this is when we've had the SLE codebase to borrow from, which dramatically reduced the work required.
Either Slowroll or Linarite would require considerably more packaging and maintenance work than Leap.
And yet, based on these survey results, we look like we're going to be replacing Leap with significantly _fewer_ contributors than we have even for Leap.
Outside of the survey, only 17 people have expressed an interest in working on a Leap replacement, and so far Slowroll and Linarite have both been one-man-shows.
Being hopeful, Slowroll does seem to be the concept that promises to convert more users into contributors.
And if we focus on Desktop-only (relying on the 1:1 ALP copies for Server) we might not need as much effort.
But I worry that we'd do more harm than good for our community to push forward towards any effort that doesn't really have much enthusiasm behind it.
The survey clearly shows a tendency for folk to believe openSUSE should do things which they themselves are not willing to contribute to.
For a Leap replacement to be viable, both to be made and then supported for years, I'm convinced we need a significant increase in folk rolling up their sleeves and working towards it.
So, I want to challenge the community with a few questions
Shall we go on with these efforts? If so, are you willing to help?
Thoughts, comments, flames all welcome
So I've seen enough from the granite discussions along with enough user and developer interest (which didn't have to be much) to want to work on / build a Granite++ I.E. Rather then just doing a 1:1 rebuild, having an additional repo similar to openSUSE_Backports for Leap and allowing contributors to submit whichever packages they feel they'd like on top. I think that this will be a sustainable approach in that Granite gives us a good base OS and we will only be adding on top of it the stuff that people care enough about to contribute and to the people who do contribute it will be more useful then plane granite plus keeping a bunch of there own packages in there home repo's. At some point I should probably also talk to the package hub team, because if they are interested in a package hub concept for ALP its likely we could also share some effort. Will it be functionally comparable with Leap, probably not will it be comparable enough to be marketed as a Leap replacement at this stage who knows. Will it be a useful standalone distro that's worth doing in my opinion yes. If it reaches the contributor and user level of something like MicroOS then i'd be willing to call it a working success. To answer your final two questions, I still plan to go ahead with these efforts once the ALP repo's are successfully synced back into OBS at least to the point of starting to get some of the packages I care about working. As for a timeframe personally i'm not planning on doing too much until Granite is a little more fleshed out and more of the package set starts being added to ALP. Otherwise it will probably lead to a bunch of duplicated effort. Finally I think slowroll is a fun concept and I look forward to seeing the results if people keep playing with the idea. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 2023-09-03 02:45, Simon Lees wrote:
So I've seen enough from the granite discussions along with enough user and developer interest (which didn't have to be much) to want to work on / build a Granite++ I.E. Rather then just doing a 1:1 rebuild, having an additional repo similar to openSUSE_Backports for Leap and allowing contributors to submit whichever packages they feel they'd like on top.
I think that this will be a sustainable approach in that Granite gives us a good base OS and we will only be adding on top of it the stuff that people care enough about to contribute and to the people who do contribute it will be more useful then plane granite plus keeping a bunch of there own packages in there home repo's. At some point I should probably also talk to the package hub team, because if they are interested in a package hub concept for ALP its likely we could also share some effort.
Will it be functionally comparable with Leap, probably not will it be comparable enough to be marketed as a Leap replacement at this stage who knows. Will it be a useful standalone distro that's worth doing in my opinion yes. If it reaches the contributor and user level of something like MicroOS then i'd be willing to call it a working success.
To answer your final two questions, I still plan to go ahead with these efforts once the ALP repo's are successfully synced back into OBS at least to the point of starting to get some of the packages I care about working. As for a timeframe personally i'm not planning on doing too much until Granite is a little more fleshed out and more of the package set starts being added to ALP. Otherwise it will probably lead to a bunch of duplicated effort.
Finally I think slowroll is a fun concept and I look forward to seeing the results if people keep playing with the idea.
Thanks for sharing your plans Simon But like you seem to accept, they may not exactly equate to a viable Leap replacement With Granite not coming until 2025 and there being no plan for a Leap 15.7, there would be a high risk of having no option for Leap users for a year or two while your idea takes form, gets developed and then released Might be all worth doing when we get there anyway but the whole point of this exercise was to see if what options were viable for the openSUSE Project take care of itself That’s why “wait and see” wasn’t an option in the poll -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
On 9/3/23 15:54, Richard Brown wrote:
On 2023-09-03 02:45, Simon Lees wrote:
So I've seen enough from the granite discussions along with enough user and developer interest (which didn't have to be much) to want to work on / build a Granite++ I.E. Rather then just doing a 1:1 rebuild, having an additional repo similar to openSUSE_Backports for Leap and allowing contributors to submit whichever packages they feel they'd like on top.
I think that this will be a sustainable approach in that Granite gives us a good base OS and we will only be adding on top of it the stuff that people care enough about to contribute and to the people who do contribute it will be more useful then plane granite plus keeping a bunch of there own packages in there home repo's. At some point I should probably also talk to the package hub team, because if they are interested in a package hub concept for ALP its likely we could also share some effort.
Will it be functionally comparable with Leap, probably not will it be comparable enough to be marketed as a Leap replacement at this stage who knows. Will it be a useful standalone distro that's worth doing in my opinion yes. If it reaches the contributor and user level of something like MicroOS then i'd be willing to call it a working success.
To answer your final two questions, I still plan to go ahead with these efforts once the ALP repo's are successfully synced back into OBS at least to the point of starting to get some of the packages I care about working. As for a timeframe personally i'm not planning on doing too much until Granite is a little more fleshed out and more of the package set starts being added to ALP. Otherwise it will probably lead to a bunch of duplicated effort.
Finally I think slowroll is a fun concept and I look forward to seeing the results if people keep playing with the idea.
Thanks for sharing your plans Simon
But like you seem to accept, they may not exactly equate to a viable Leap replacement
With Granite not coming until 2025 and there being no plan for a Leap 15.7, there would be a high risk of having no option for Leap users for a year or two while your idea takes form, gets developed and then released
Well from my maths a 15.6 mid 2024 + 18 months of support lands us at the end of 2025 and while now is probably too early to work on something I'd hope that we'd be able to work on something in parallel with granite development through 2025 so that we have something viable by the end of 2025, As long as all the key components of Granite are in place I also wouldn't rule out trying to release something a little before the granite release maybe within the Beta period if it helps with time frames. This might not meet every need of every existing Leap user but it would certainly be my goal to meet the needs of as many as we reasonably can so there is atleast some choice for people who don't wish to move to full tumbleweed. Of course from these numbers we might not get the general 6 months we have for migration between current point releases but unless Granite releases in December of 2025 hopefully we can get more then a month. If toward the end of 2025 we look like we have a viable replacement but might ideally need a little more time for migration then i'd certainly consider getting the board to approach SUSE about maybe the possibility of moving from 18 months of support to maybe 21 for 15.6. But either way at this stage i'm certainly not seeing a period where there'd be a year or two of completely unsupported systems. Given how similar the planned approach is to Leap and the fact we were able to put together a prototype in a week based off just the Marble codebase the design is mostly there and really all we are waiting for is some up to date ALP sources to hit OBS it doesn't really need to be all of Granite either if we just start working with a smaller subset of packages until the core of ALP starts to land and we build more on top of it. -- 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 2023-09-04 04:09, Simon Lees wrote:
On 9/3/23 15:54, Richard Brown wrote:
On 2023-09-03 02:45, Simon Lees wrote: With Granite not coming until 2025 and there being no plan for a Leap 15.7, there would be a high risk of having no option for Leap users for a year or two while your idea takes form, gets developed and then released
Well from my maths a 15.6 mid 2024 + 18 months of support lands us at the end of 2025 and while now is probably too early to work on something I'd hope that we'd be able to work on something in parallel with granite development through 2025 so that we have something viable by the end of 2025, As long as all the key components of Granite are in place I also wouldn't rule out trying to release something a little before the granite release maybe within the Beta period if it helps with time frames. This might not meet every need of every existing Leap user but it would certainly be my goal to meet the needs of as many as we reasonably can so there is atleast some choice for people who don't wish to move to full tumbleweed.
Of course from these numbers we might not get the general 6 months we have for migration between current point releases but unless Granite releases in December of 2025 hopefully we can get more then a month. If toward the end of 2025 we look like we have a viable replacement but might ideally need a little more time for migration then i'd certainly consider getting the board to approach SUSE about maybe the possibility of moving from 18 months of support to maybe 21 for 15.6. But either way at this stage i'm certainly not seeing a period where there'd be a year or two of completely unsupported systems.
Given how similar the planned approach is to Leap and the fact we were able to put together a prototype in a week based off just the Marble codebase the design is mostly there and really all we are waiting for is some up to date ALP sources to hit OBS it doesn't really need to be all of Granite either if we just start working with a smaller subset of packages until the core of ALP starts to land and we build more on top of it.
There are teams (including one with your dayjobs Teamlead) looking at topics for Granite like: - reducing the packages delivered in Granite to make it more sustainably supportable - “compartmentalising” software stacks so SUSE may use different versions of stuff from the users, enabling different lifecycles either for SUSE or the users over the lifespan of Granite Neither of the above will apply to Marble. If either of these efforts has any impact on the Granite codebase then I expect your proposed timeline above to be utterly infeasible. I expect both efforts to have a dramatic impact on the internals of Granite even if the end goal is that users won’t see much of a difference compared to a SLES major release. I really do not share your optimism at all that the openSUSE Project will have the time, resources or capability to design, build, and make a reliable new distro based on Granite before the end of life of Leap 15.6 If I thought that was a viable option I absolutely wouldn’t be doing what I have been trying to bring folk together to build a Leap replacement. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
On 9/4/23 15:36, Richard Brown wrote:
On 2023-09-04 04:09, Simon Lees wrote:
On 9/3/23 15:54, Richard Brown wrote:
On 2023-09-03 02:45, Simon Lees wrote: With Granite not coming until 2025 and there being no plan for a Leap 15.7, there would be a high risk of having no option for Leap users for a year or two while your idea takes form, gets developed and then released
Well from my maths a 15.6 mid 2024 + 18 months of support lands us at the end of 2025 and while now is probably too early to work on something I'd hope that we'd be able to work on something in parallel with granite development through 2025 so that we have something viable by the end of 2025, As long as all the key components of Granite are in place I also wouldn't rule out trying to release something a little before the granite release maybe within the Beta period if it helps with time frames. This might not meet every need of every existing Leap user but it would certainly be my goal to meet the needs of as many as we reasonably can so there is atleast some choice for people who don't wish to move to full tumbleweed.
Of course from these numbers we might not get the general 6 months we have for migration between current point releases but unless Granite releases in December of 2025 hopefully we can get more then a month. If toward the end of 2025 we look like we have a viable replacement but might ideally need a little more time for migration then i'd certainly consider getting the board to approach SUSE about maybe the possibility of moving from 18 months of support to maybe 21 for 15.6. But either way at this stage i'm certainly not seeing a period where there'd be a year or two of completely unsupported systems.
Given how similar the planned approach is to Leap and the fact we were able to put together a prototype in a week based off just the Marble codebase the design is mostly there and really all we are waiting for is some up to date ALP sources to hit OBS it doesn't really need to be all of Granite either if we just start working with a smaller subset of packages until the core of ALP starts to land and we build more on top of it.
There are teams (including one with your dayjobs Teamlead) looking at topics for Granite like:
- reducing the packages delivered in Granite to make it more sustainably supportable - “compartmentalising” software stacks so SUSE may use different versions of stuff from the users, enabling different lifecycles either for SUSE or the users over the lifespan of Granite
Of this i'm well aware given that I have also been involved in both workgroups (although not always in the meetings due to timezones).
Neither of the above will apply to Marble.
On the contrary compared to what I was expecting when I did my prototype and basing of marble, every discussion around package selection was working around a significantly smaller and harder package set to deal with then what's being discussed for Granite currently. Yes how we work with compartmentalization long term is a challenge that still needs to be addressed, however I highly suspect for atleast the initial release of Granite there will probably only be one of most stacks. But yes how we tell a project which packages to ignore is something to solve in the next 18 months. Ideally we will be able to start pulling openSUSE packages from Tumbleweed at the same time or a similar time as they are so the "Factory First" if Factory works so does everything else still applies. But there maybe some things that need addressing yes.
If either of these efforts has any impact on the Granite codebase then I expect your proposed timeline above to be utterly infeasible.
I expect both efforts to have a dramatic impact on the internals of Granite even if the end goal is that users won’t see much of a difference compared to a SLES major release.
I really do not share your optimism at all that the openSUSE Project will have the time, resources or capability to design, build, and make a reliable new distro based on Granite before the end of life of Leap 15.6
Well i'm the sort of person that will take the goal of having a distro based on Granite before the end of 15.6 and push my hardest to resolve the issues to get there and if come September / October 2025 that is looking unlikely i'd start to look at temporary work arounds to bridge the gap. This could include asking SUSE nicely if they'd consider a one off extension to 15.6 support to help "Bridge the Gap", or maybe it could involve a "temporary rolling setup" based on the current state of where we get to that people may chose to use until we get to the point of being able to coin a stable release. Yes these options are less then ideal and the first might not even be possible but personally for my own needs i'd happily take less then ideal over nothing.
If I thought that was a viable option I absolutely wouldn’t be doing what I have been trying to bring folk together to build a Leap replacement.
And I'm aiming to bring people together to work on proving that it is a viable option. Or atleast enough of a viable option to meet the needs of those willing to contribute. The History of Leap shows that even if we can achieve that standard for a small number of contributors we can come up with something that is quite useful for users. -- 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 Sun, Sep 03, 2023 at 08:24:28AM +0200, Richard Brown wrote:
On 2023-09-03 02:45, Simon Lees wrote:
So I've seen enough from the granite discussions along with enough user and developer interest (which didn't have to be much) to want to work on / build a Granite++ I.E. Rather then just doing a 1:1 rebuild, having an additional repo similar to openSUSE_Backports for Leap and allowing contributors to submit whichever packages they feel they'd like on top.
I think that this will be a sustainable approach in that Granite gives us a good base OS and we will only be adding on top of it the stuff that people care enough about to contribute and to the people who do contribute it will be more useful then plane granite plus keeping a bunch of there own packages in there home repo's. At some point I should probably also talk to the package hub team, because if they are interested in a package hub concept for ALP its likely we could also share some effort.
Will it be functionally comparable with Leap, probably not will it be comparable enough to be marketed as a Leap replacement at this stage who knows. Will it be a useful standalone distro that's worth doing in my opinion yes. If it reaches the contributor and user level of something like MicroOS then i'd be willing to call it a working success.
To answer your final two questions, I still plan to go ahead with these efforts once the ALP repo's are successfully synced back into OBS at least to the point of starting to get some of the packages I care about working. As for a timeframe personally i'm not planning on doing too much until Granite is a little more fleshed out and more of the package set starts being added to ALP. Otherwise it will probably lead to a bunch of duplicated effort.
Finally I think slowroll is a fun concept and I look forward to seeing the results if people keep playing with the idea.
Thanks for sharing your plans Simon
But like you seem to accept, they may not exactly equate to a viable Leap replacement
With Granite not coming until 2025 and there being no plan for a Leap 15.7, there would be a high risk of having no option for Leap users for a year or two while your idea takes form, gets developed and then released
And why is there no plan for LEap 15.7? From what I can see we are uncertain that we can build something based on ALP to replace Leap 15.6 before its EPL yet Leap 15.7 whould give a timeline that makes the replacement much more feasible. Thanks Michal
On 2023-09-04 08:34, Michal Suchánek wrote:
With Granite not coming until 2025 and there being no plan for a Leap 15.7, there would be a high risk of having no option for Leap users for a year or two while your idea takes form, gets developed and then released
And why is there no plan for LEap 15.7?
Because of several reasons - the general agreement of Leaps use of SLE sources was with the condition that openSUSE would always transition to the next Enterprise codebase when it exists. Now ALP is here, it exists. The fact that it exists in a different scope than previous Enterprise codebases is a fact that openSUSE needs to rise to address - this is proving hard already - making a 15.7 will just make that harder. - the folk that SUSE contributes to make Leap are also the same folk you’ll need to make and support a 15.7. We could really use their help to build a Leap replacement. So if I were to push for a 15.7, that would mean we’d have to find even more new folk to lead, release manage, build and maintain a Leap replacement. I’d rather see the Leap pros working on a platform that has a future in the Project rather than losing them for a year or two maintaining a platform with no future. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
On Mon, Sep 04, 2023 at 08:47:19AM +0200, Richard Brown wrote:
On 2023-09-04 08:34, Michal Suchánek wrote:
With Granite not coming until 2025 and there being no plan for a Leap 15.7, there would be a high risk of having no option for Leap users for a year or two while your idea takes form, gets developed and then released
And why is there no plan for LEap 15.7?
Because of several reasons
- the general agreement of Leaps use of SLE sources was with the condition that openSUSE would always transition to the next Enterprise codebase when it exists. Now ALP is here, it exists. The fact that it exists in a different scope than previous Enterprise codebases is a fact that openSUSE needs to rise to address - this is proving hard already - making a 15.7 will just make that harder.
- the folk that SUSE contributes to make Leap are also the same folk you’ll need to make and support a 15.7. We could really use their help to build a Leap replacement. So if I were to push for a 15.7, that would mean we’d have to find even more new folk to lead, release manage, build and maintain a Leap replacement. I’d rather see the Leap pros working on a platform that has a future in the Project rather than losing them for a year or two maintaining a platform with no future.
Not really. Moving from Leap 15.6 to ALP means moving to ALP when it does not exist yet. There is a prototype but not a finished thing. Moving from Leap 15.7 to ALP means that the new codebase to move to is available to move to. From the discussion so far it looks like moving from Leap 15.6 to ALP is in fact closer to losing the Leap contributors for a year trying to build on top of something that does not exist than moving from Leap 15.7 does. Inevitably doing the move will mean maintaining the old while building the for some time, as was the case with Jump. And this time the difference betwen the old and the new is bigger so it will take more time to get something working. Sure, abandoning the concept of building on top of SUSE distribution is a possibility. Doing that only because of the release timing for 15.6 vs ALP does not sound like a great decision. Thanks Michal
On 2023-09-04 10:04, Michal Suchánek wrote:
On Mon, Sep 04, 2023 at 08:47:19AM +0200, Richard Brown wrote:
On 2023-09-04 08:34, Michal Suchánek wrote:
With Granite not coming until 2025 and there being no plan for a Leap 15.7, there would be a high risk of having no option for Leap users for a year or two while your idea takes form, gets developed and then released
And why is there no plan for LEap 15.7?
Because of several reasons
- the general agreement of Leaps use of SLE sources was with the condition that openSUSE would always transition to the next Enterprise codebase when it exists. Now ALP is here, it exists. The fact that it exists in a different scope than previous Enterprise codebases is a fact that openSUSE needs to rise to address - this is proving hard already - making a 15.7 will just make that harder.
- the folk that SUSE contributes to make Leap are also the same folk you’ll need to make and support a 15.7. We could really use their help to build a Leap replacement. So if I were to push for a 15.7, that would mean we’d have to find even more new folk to lead, release manage, build and maintain a Leap replacement. I’d rather see the Leap pros working on a platform that has a future in the Project rather than losing them for a year or two maintaining a platform with no future.
Not really. Moving from Leap 15.6 to ALP means moving to ALP when it does not exist yet. There is a prototype but not a finished thing.
Moving from Leap 15.7 to ALP means that the new codebase to move to is available to move to.
I thought I said this clearly enough, but I'll say it very bluntly If we do for 15.7, we won't be able to rely on the SUSE-paid employees who work on Leap to help with the Leap replacement, because they'll be busy with 15.7 We don't have any extra hands from SUSE to work on this - for example, some people have suggested I'll be building the Leap replacement. I won't, my involvement here is purely as an Architect, trying to help design whatever next. Given the poll clearly shows that we're doing this with, at best, luke-warm interest from the community to contribute, we absolutely need as much SUSE-sponsored help as we can get It's my very strong opinion, based on the enthusiasm shown so far for a Leap replacement, that if I were to persuade SUSE to sponsor the work for a 15.7, that 15.7 will not just be the last Leap release, but we'll almost certainly have no replacement going forward. Maybe thats a good way forward, maybe that's where we'll end up, but I was approaching this problem with a view to having a solution that will last beyond 2026, so I don't favour this option. Regards, -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
On Mon, Sep 04, 2023 at 10:13:43AM +0200, Richard Brown wrote:
On 2023-09-04 10:04, Michal Suchánek wrote:
On Mon, Sep 04, 2023 at 08:47:19AM +0200, Richard Brown wrote:
On 2023-09-04 08:34, Michal Suchánek wrote:
With Granite not coming until 2025 and there being no plan for a Leap 15.7, there would be a high risk of having no option for Leap users for a year or two while your idea takes form, gets developed and then released
And why is there no plan for LEap 15.7?
Because of several reasons
- the general agreement of Leaps use of SLE sources was with the condition that openSUSE would always transition to the next Enterprise codebase when it exists. Now ALP is here, it exists. The fact that it exists in a different scope than previous Enterprise codebases is a fact that openSUSE needs to rise to address - this is proving hard already - making a 15.7 will just make that harder.
- the folk that SUSE contributes to make Leap are also the same folk you’ll need to make and support a 15.7. We could really use their help to build a Leap replacement. So if I were to push for a 15.7, that would mean we’d have to find even more new folk to lead, release manage, build and maintain a Leap replacement. I’d rather see the Leap pros working on a platform that has a future in the Project rather than losing them for a year or two maintaining a platform with no future.
Not really. Moving from Leap 15.6 to ALP means moving to ALP when it does not exist yet. There is a prototype but not a finished thing.
Moving from Leap 15.7 to ALP means that the new codebase to move to is available to move to.
I thought I said this clearly enough, but I'll say it very bluntly
If we do for 15.7, we won't be able to rely on the SUSE-paid employees who work on Leap to help with the Leap replacement, because they'll be busy with 15.7
And how does that change between 15.6 and 15.7? Won't people be busy with 15.6 at 15.6 time as much as they would be busy with 15.7 at 15.7 time? The difference is only on the ALP side - at 15.7 time it will be much more mature base to build on. Thanks Michal
On 2023-09-04 10:37, Michal Suchánek wrote:
On Mon, Sep 04, 2023 at 10:13:43AM +0200, Richard Brown wrote:
On 2023-09-04 10:04, Michal Suchánek wrote:
I thought I said this clearly enough, but I'll say it very bluntly
If we do for 15.7, we won't be able to rely on the SUSE-paid employees who work on Leap to help with the Leap replacement, because they'll be busy with 15.7
And how does that change between 15.6 and 15.7?
Won't people be busy with 15.6 at 15.6 time as much as they would be busy with 15.7 at 15.7 time?
The difference is only on the ALP side - at 15.7 time it will be much more mature base to build on.
Leap 15.6 is being bootstrapped right now (https://build.opensuse.org/project/show/openSUSE:Leap:15.6) It will be completed and off the desk of the majority of the SUSE-paid Leap folk in time for them to get something like Slowroll in place and well established by the end of Leap 15.6's end of life If we do a 15.7, they'll be spending their time on that instead. Meanwhile ALP will not magically become a 'more mature base to build on' openSUSE Leap is a very Desktop-centric distribution. None of SUSE's planned ALP products have any intention of being a Desktop-centric offering. If openSUSE doesn't start the work now, then ALP will never be ready for the Desktop use cases we currently enjoy with Leap. (the Server use cases should be well served by the 1:1 copies of SUSE's ALP products we'll be doing) If we choose to kick the can down the road, all we end up with is the same mountain to climb and more tired legs for spending another year building Leap. If that is our collective desire, I think that would be an utter waste of our time so you can expect me to step back and leave that challenge to someone else to make sense out of. There's plenty more interesting things for me to work on. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblic
On Mon, Sep 04, 2023 at 11:34:43AM +0200, Richard Brown wrote:
On 2023-09-04 10:37, Michal Suchánek wrote:
On Mon, Sep 04, 2023 at 10:13:43AM +0200, Richard Brown wrote:
On 2023-09-04 10:04, Michal Suchánek wrote:
I thought I said this clearly enough, but I'll say it very bluntly
If we do for 15.7, we won't be able to rely on the SUSE-paid employees who work on Leap to help with the Leap replacement, because they'll be busy with 15.7
And how does that change between 15.6 and 15.7?
Won't people be busy with 15.6 at 15.6 time as much as they would be busy with 15.7 at 15.7 time?
The difference is only on the ALP side - at 15.7 time it will be much more mature base to build on.
Leap 15.6 is being bootstrapped right now (https://build.opensuse.org/project/show/openSUSE:Leap:15.6)
It will be completed and off the desk of the majority of the SUSE-paid Leap folk in time for them to get something like Slowroll in place and well established by the end of Leap 15.6's end of life
And how it differs if we decide to make it after 15.7 release instead?
If we do a 15.7, they'll be spending their time on that instead.
Until 15.7 is done, and then have time to work on replacement then, same. Except with extra time to look at ALP and how it works during the 15.6 maintenance.
Meanwhile ALP will not magically become a 'more mature base to build on'
openSUSE Leap is a very Desktop-centric distribution.
None of SUSE's planned ALP products have any intention of being a Desktop-centric offering.
However, the ALP base is not ready now, and it will be very fresh and rough around the edges if done at all at the time 15.6 is released.
If openSUSE doesn't start the work now, then ALP will never be ready for the Desktop use cases we currently enjoy with Leap. (the Server use cases should be well served by the 1:1 copies of SUSE's ALP products we'll be doing)
If we choose to kick the can down the road, all we end up with is the same mountain to climb and more tired legs for spending another year building Leap.
There have been like 10 Leap releases, and with the next people will suddenly become tired out significantly more than before? It looks to me like you are going for false dichotomy here. Sure, building a Leap replacement is non-trivial undertaking whether it's done at Leap 15.6 time or Leap 15.7 time. I don'tr really see how making 15.7 puts us in worse position for making the replacement, though. Thanks Michal
On 9/4/23 19:04, Richard Brown wrote:
On 2023-09-04 10:37, Michal Suchánek wrote:
On Mon, Sep 04, 2023 at 10:13:43AM +0200, Richard Brown wrote:
On 2023-09-04 10:04, Michal Suchánek wrote:
I thought I said this clearly enough, but I'll say it very bluntly
If we do for 15.7, we won't be able to rely on the SUSE-paid employees who work on Leap to help with the Leap replacement, because they'll be busy with 15.7
And how does that change between 15.6 and 15.7?
Won't people be busy with 15.6 at 15.6 time as much as they would be busy with 15.7 at 15.7 time?
The difference is only on the ALP side - at 15.7 time it will be much more mature base to build on.
Leap 15.6 is being bootstrapped right now (https://build.opensuse.org/project/show/openSUSE:Leap:15.6)
It will be completed and off the desk of the majority of the SUSE-paid Leap folk in time for them to get something like Slowroll in place and well established by the end of Leap 15.6's end of life
If we do a 15.7, they'll be spending their time on that instead.
Meanwhile ALP will not magically become a 'more mature base to build on'
openSUSE Leap is a very Desktop-centric distribution.
None of SUSE's planned ALP products have any intention of being a Desktop-centric offering.
If openSUSE doesn't start the work now, then ALP will never be ready for the Desktop use cases we currently enjoy with Leap. (the Server use cases should be well served by the 1:1 copies of SUSE's ALP products we'll be doing)
I actually aimed to start on this a good few weeks back, but at the time SUSE's ALP packages weren't being synced to the public build service, has there been any change there? because really that's all i'm waiting on to start spending some time here. -- 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 02/09/2023 10.19, Richard Brown wrote:
"Slowroll" - a derivative of Tumbleweed, built automatically as much as possible, using automation and metrics to copy packages from Tumbleweed only after certain conditions (max age, X weeks without change, etc). Basically an attempt to provide something less scary than full speed Tumbleweed.
https://en.opensuse.org/openSUSE:Slowroll PoC is up for testing. Current base snapshot is TW-20230822 with the next bump expected end of September On the ToDo list: - proper repo setup (e.g. in openSUSE:Slowroll) - staging + openQA setup - own install / VM / container images - script a consideration for package dependencies - find a solution for missing unpublished -bootstrap packages [1] If you want to help, feel free to email me. [1] see 'unresolvable' in https://build.opensuse.org/package/show/openSUSE:ALP:Experimental:Slowroll/j...
Bernhard M. Wiedemann composed on 2023-09-04 09:55 (UTC+0200):
PoC is up for testing.
Current base snapshot is TW-20230822
My first choice for a switch turned out to be 20230823, so instead I chose a UEFI 15.5 to dup from. It includes Plasma, IceWM and instead of SDDM, KDM3. Libdvdcss: Use TW, or latest Leap? openh264: same? For the time being, no need for Packman here, but eventually, and others, ..... Whatever mirror CDN is providing for FL, USA is distinctly unimpressive. Unfortunately I forgot to time the -d step. Actual installation time for 1148 packages, including several selection stops for fonts I don't allow to waste resources: ... Executing %posttrans scripts ..........................................................................................................................................................[done] warning: Found NDB Packages.db database while attempting bdb backend: using ndb backend. CommitResult (total 1148, done 1148, error 0, skipped 0, updateMessages 0) Checking for running processes using deleted libraries... warning: Found NDB Packages.db database while attempting bdb backend: using ndb backend. There are running programs which still use files and libraries deleted or updated by recent upgrades. They should be restarted to benefit from the latest updates. Run 'zypper ps -s' to list these programs. real 2m33.846s user 0m48.026s sys 0m20.259s # zypper -v dup Verbosity: 2 Initializing Target Checking whether to refresh metadata for Non-OSS Checking whether to refresh metadata for OSS Checking whether to refresh metadata for Update ... Computing upgrade... Problem: the installed libldap-2_4-2-2.4.46-150200.14.17.1.x86_64 requires 'libldap-data = 2.4.46-150200.14.17.1', but this requirement cannot be provided deleted providers: libldap-data-2.4.46-150200.14.17.1.noarch Solution 1: Following actions will be done: deinstallation of kdebase3-runtime-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-kdm-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-apps-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-3.5.10.1-lp155.379.1.x86_64 Solution 2: keep obsolete libldap-data-2.4.46-150200.14.17.1.noarch Solution 3: break libldap-2_4-2-2.4.46-150200.14.17.1.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): 2 ... # cat /usr/local/bin/zypse #!/bin/sh zypper --no-refresh se -s $* | grep -Ev '32bit|debug|devel|srcp|openSUSE-20' | grep -E 'x86|noarch'| sort # zypse libldap i | libldap-2_4-2 | package | 2.4.46-150200.14.17.1 | x86_64 | (System Packages) i | libldap2 | package | 2.6.4-2.3 | x86_64 | OSS i | libldapcpp0 | package | 2.6.4-2.2 | x86_64 | OSS i+ | libldap-data | package | 2.4.46-150200.14.17.1 | noarch | (System Packages) v | libldap-data | package | 2.6.4-2.3 | noarch | OSS # Is there expected to be a KDE3 repo for Slowroll? Should I use TW's for the time being? Just keep old libldap* as long as allowed? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Felix Miata composed on 2023-09-05 23:20 (UTC-0400):
Bernhard M. Wiedemann composed on 2023-09-04 09:55 (UTC+0200):
PoC is up for testing.
Current base snapshot is TW-20230822
My first choice for a switch turned out to be 20230823, so instead I chose a UEFI 15.5 to dup from. It includes Plasma, IceWM and instead of SDDM, KDM3.
Libdvdcss: Use TW, or latest Leap?
openh264: same?
For the time being, no need for Packman here, but eventually, and others, .....
Whatever mirror CDN is providing for FL, USA is distinctly unimpressive. Unfortunately I forgot to time the -d step. Actual installation time for 1148 packages, including several selection stops for fonts I don't allow to waste resources: ... Executing %posttrans scripts ..........................................................................................................................................................[done] warning: Found NDB Packages.db database while attempting bdb backend: using ndb backend. CommitResult (total 1148, done 1148, error 0, skipped 0, updateMessages 0) Checking for running processes using deleted libraries... warning: Found NDB Packages.db database while attempting bdb backend: using ndb backend. There are running programs which still use files and libraries deleted or updated by recent upgrades. They should be restarted to benefit from the latest updates. Run 'zypper ps -s' to list these programs.
real 2m33.846s user 0m48.026s sys 0m20.259s # zypper -v dup Verbosity: 2 Initializing Target Checking whether to refresh metadata for Non-OSS Checking whether to refresh metadata for OSS Checking whether to refresh metadata for Update ... Computing upgrade...
Problem: the installed libldap-2_4-2-2.4.46-150200.14.17.1.x86_64 requires 'libldap-data = 2.4.46-150200.14.17.1', but this requirement cannot be provided deleted providers: libldap-data-2.4.46-150200.14.17.1.noarch Solution 1: Following actions will be done: deinstallation of kdebase3-runtime-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-kdm-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-apps-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-3.5.10.1-lp155.379.1.x86_64 Solution 2: keep obsolete libldap-data-2.4.46-150200.14.17.1.noarch Solution 3: break libldap-2_4-2-2.4.46-150200.14.17.1.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): 2 ... # cat /usr/local/bin/zypse #!/bin/sh zypper --no-refresh se -s $* | grep -Ev '32bit|debug|devel|srcp|openSUSE-20' | grep -E 'x86|noarch'| sort # zypse libldap i | libldap-2_4-2 | package | 2.4.46-150200.14.17.1 | x86_64 | (System Packages) i | libldap2 | package | 2.6.4-2.3 | x86_64 | OSS i | libldapcpp0 | package | 2.6.4-2.2 | x86_64 | OSS i+ | libldap-data | package | 2.4.46-150200.14.17.1 | noarch | (System Packages) v | libldap-data | package | 2.6.4-2.3 | noarch | OSS #
Is there expected to be a KDE3 repo for Slowroll? Should I use TW's for the time being? Just keep old libldap* as long as allowed?
I forgot to reboot before sending. Instead of a PlasmaX11 session from KDM3, I get what looks like a decorations-free Xterm. /usr/bin/startplasma-x11 seems to mostly work, but initially didn't open the unclosed Konsole3 session expected to be restored, and there was a "DCOP communications error (Konsole)" popup "could not read network connection list" that needed dismissal first. Killing the frameless Xterm killed the plasma session, and another refused to start even after rebooting. Trying to start IceWM from KDM3 initially fails in same manner as plasmaX11 by providing only a windowless Xterm, but /usr/bin/icewm doesn't refuse restart after exiting. Eventually emptying ~/.cache/ enabled Plasma to run successfully again repeatedly, though not without the extra startup activity for every session: # inxi -GSaz --vs --zl --hostname inxi 3.3.29-00 (2023-08-15) System: Host: ab560 Kernel: 6.4.12-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.2.1 clocksource: tsc available: hpet,acpi_pm parameters: BOOT_IMAGE=/boot/vmlinuz root=LABEL=<filter> noresume ipv6.disable=1 net.ifnames=0 consoleblank=0 preempt=full mitigations=off Desktop: KDE Plasma v: 5.27.7 tk: Qt v: 5.15.10 wm: kwin_x11 vt: 7 dm: 1: KDM 2: XDM Distro: openSUSE Tumbleweed 20230822 Graphics: Device-1: Intel RocketLake-S GT1 [UHD Graphics 730] vendor: ASUSTeK driver: i915 v: kernel arch: Gen-12.1 process: Intel 10nm built: 2020-21 ports: active: DP-1,HDMI-A-1,HDMI-A-2 empty: HDMI-A-3 bus-ID: 00:02.0 chip-ID: 8086:4c8b class-ID: 0300 Display: x11 server: X.Org v: 21.1.8 compositor: kwin_x11 driver: X: loaded: modesetting unloaded: fbdev,vesa alternate: intel dri: iris gpu: i915 display-ID: :0 screens: 1 Screen-1: 0 s-res: 6160x1440 s-dpi: 120 s-size: 1303x304mm (51.30x11.97") s-diag: 1338mm (52.68") Monitor-1: DP-1 pos: right model: Acer K272HUL serial: <filter> built: 2018 res: 2560x1440 hz: 60 dpi: 109 gamma: 1.2 size: 598x336mm (23.54x13.23") diag: 686mm (27") ratio: 16:9 modes: max: 2560x1440 min: 720x400 Monitor-2: HDMI-A-1 mapped: HDMI-1 pos: primary,left model: NEC EA243WM serial: <filter> built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2 size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes: max: 1920x1200 min: 640x480 Monitor-3: HDMI-A-2 mapped: HDMI-2 pos: center model: Dell P2213 serial: <filter> built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2 size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes: max: 1680x1050 min: 720x400 API: OpenGL v: 4.6 Mesa 23.1.5 renderer: Mesa Intel Graphics (RKL GT1) direct-render: Yes # inxi hasn't heard of Slowroll before now. :p But, /etc/os-release doesn't mention Slowroll either. O_O -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 06/09/2023 05.20, Felix Miata wrote:
Solution 1: Following actions will be done: > deinstallation of kdebase3-runtime-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-kdm-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-apps-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-3.5.10.1-lp155.379.1.x86_64
That seems to be the sane way out there. I don't think we want to keep supporting KDE3 when 13.2 was the last release to ship it. EOL 6y ago. Slowroll is just meant to be a variant of TW/Factory that moves slower to hopefully cause less bugs along the way, but it won't magically support things that TW doesn't. Ciao Bernhard M.
Bernhard M. Wiedemann composed on 2023-09-07 08:26 (UTC+0200):
Felix Miata wrote:
Solution 1: Following actions will be done: deinstallation of kdebase3-runtime-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-kdm-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-apps-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-3.5.10.1-lp155.379.1.x86_64
That seems to be the sane way out there. I don't think we want to keep supporting KDE3 when 13.2 was the last release to ship it. EOL 6y ago.
Slowroll is just meant to be a variant of TW/Factory that moves slower to hopefully cause less bugs along the way, but it won't magically support things that TW doesn't.
Somebody is providing KDE3 for Leap and TW in oSBS[*]. :-D My current primary is 15.5, running KDE3 ever since I started using SUSE with 8.0. I have 12 64bit KDE3 installations on TW, a smaller bunch on 32bit, and 6 TW/Plasma installations using KDM3 instead of that SDDM crippler that I suffer on 2 TW/Plasmas. As was with Leap Alpha/Beta, I'll have close to half my two-dozen+ 15.6s with KDE3 by the time of 15.6 GM. These are all on hardware multiboot, no VMs except for running DOS SVGA text mode on OS/2. [*] http://download.opensuse.org/repositories/KDE:/KDE3/15.4/ http://download.opensuse.org/repositories/KDE:/KDE3/15.5/ http://download.opensuse.org/repositories/KDE:/KDE3/15.6/ http://download.opensuse.org/repositories/KDE:/KDE3/16.0/ http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Leap_15.1/ http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Leap_15.2_ARM/ http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Tumbleweed/ (I'm wondering if 16.0 might be intended for Slowroll, locally nicked sslo.) -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 9/7/23 17:36, Felix Miata wrote:
Bernhard M. Wiedemann composed on 2023-09-07 08:26 (UTC+0200):
Felix Miata wrote:
Solution 1: Following actions will be done: deinstallation of kdebase3-runtime-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-kdm-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-apps-3.5.10.1-lp155.379.1.x86_64 deinstallation of kdebase3-3.5.10.1-lp155.379.1.x86_64
That seems to be the sane way out there. I don't think we want to keep supporting KDE3 when 13.2 was the last release to ship it. EOL 6y ago.
Slowroll is just meant to be a variant of TW/Factory that moves slower to hopefully cause less bugs along the way, but it won't magically support things that TW doesn't.
Somebody is providing KDE3 for Leap and TW in oSBS[*]. :-D My current primary is 15.5, running KDE3 ever since I started using SUSE with 8.0. I have 12 64bit KDE3 installations on TW, a smaller bunch on 32bit, and 6 TW/Plasma installations using KDM3 instead of that SDDM crippler that I suffer on 2 TW/Plasmas. As was with Leap Alpha/Beta, I'll have close to half my two-dozen+ 15.6s with KDE3 by the time of 15.6 GM. These are all on hardware multiboot, no VMs except for running DOS SVGA text mode on OS/2.
They'd also need to build that repo against slowroll, anything else is likely to have issues.
[*] http://download.opensuse.org/repositories/KDE:/KDE3/15.4/ http://download.opensuse.org/repositories/KDE:/KDE3/15.5/ http://download.opensuse.org/repositories/KDE:/KDE3/15.6/ http://download.opensuse.org/repositories/KDE:/KDE3/16.0/ http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Leap_15.1/ http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Leap_15.2_ARM/ http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Tumbleweed/ (I'm wondering if 16.0 might be intended for Slowroll, locally nicked sslo.)
Nope it was for an ALP based prototype -- 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
Hey! Just decided to test in a Virtualbox VM and both install and changing repos to update from 22th August to 30th August worked https://i.imgur.com/CASlms8.png Den mån 4 sep. 2023 kl 09:55 skrev Bernhard M. Wiedemann via openSUSE Factory <factory@lists.opensuse.org>:
On 02/09/2023 10.19, Richard Brown wrote:
"Slowroll" - a derivative of Tumbleweed, built automatically as much as possible, using automation and metrics to copy packages from Tumbleweed only after certain conditions (max age, X weeks without change, etc). Basically an attempt to provide something less scary than full speed Tumbleweed.
https://en.opensuse.org/openSUSE:Slowroll
PoC is up for testing.
Current base snapshot is TW-20230822 with the next bump expected end of September
On the ToDo list: - proper repo setup (e.g. in openSUSE:Slowroll) - staging + openQA setup - own install / VM / container images - script a consideration for package dependencies - find a solution for missing unpublished -bootstrap packages [1]
If you want to help, feel free to email me.
[1] see 'unresolvable' in https://build.opensuse.org/package/show/openSUSE:ALP:Experimental:Slowroll/j...
Bernhard M. Wiedemann composed on 2023-09-04 09:55 (UTC+0200):
PoC is up for testing.
Current base snapshot is TW-20230822 with the next bump expected end of September
On the ToDo list: - proper repo setup (e.g. in openSUSE:Slowroll) - staging + openQA setup - own install / VM / container images - script a consideration for package dependencies - find a solution for missing unpublished -bootstrap packages [1]
If you want to help, feel free to email me.
Just finished a successful and uneventful 1200 transaction zypper dup from tw20230708 with the following: # zypper lr | grep Yes 1 | FCLunst | Yes | ( p) Yes | http://silk.apana.org.au/rpm-unstable-dev 2 | KDE3 | Yes | (r ) Yes | http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Tumbleweed/ 3 | Non-OSS | Yes | (r ) Yes | http://cdn.opensuse.org/repositories/openSUSE:/ALP:/Experimental:/Slowroll/b... 4 | OSS | Yes | (r ) Yes | http://cdn.opensuse.org/repositories/openSUSE:/ALP:/Experimental:/Slowroll/b... 5 | Update | Yes | (r ) Yes | http://cdn.opensuse.org/repositories/openSUSE:/ALP:/Experimental:/Slowroll/s... 6 | openh264 | Yes | (r ) Yes | http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed/ # rpm -qa | grep -E 'lasm|kdm|ddm|tdm|xdm' | grep -v randi | sort kdebase3-kdm-3.5.10.1-379.1.x86_64 libKF5Plasma5-5.109.0-1.1.x86_64 plasma-framework-5.109.0-1.1.x86_64 plasma-framework-components-5.109.0-1.1.x86_64 plasma5-desktop-5.27.7.1-1.2.x86_64 plasma5-integration-plugin-5.27.7-1.1.x86_64 plasma5-session-5.27.7-3.1.noarch plasma5-workspace-5.27.7-3.1.x86_64 plasma5-workspace-libs-5.27.7-3.1.x86_64 xdm-1.1.14-4.3.x86_64 # inxi -Saz --vs --zl --hostname inxi 3.3.29-00 (2023-08-15) System: Host: gb970 Kernel: 6.4.12-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.2.1 clocksource: tsc available: hpet,acpi_pm parameters: root=LABEL=<filter> ipv6.disable=1 net.ifnames=0 noresume consoleblank=0 preempt=full mitigations=off Desktop: KDE Plasma v: 5.27.7 tk: Qt v: 5.15.10 wm: kwin_x11 dm: 1: KDM 2: XDM Distro: openSUSE Tumbleweed 20230822 # inxi -CGnz CPU: Info: quad core model: AMD Phenom II X4 965 bits: 64 type: MCP cache: L2: 2 MiB Speed (MHz): avg: 3423 min/max: N/A cores: 1: 3423 2: 3423 3: 3423 4: 3423 Graphics: Device-1: NVIDIA GF108 [GeForce GT 630] driver: nouveau v: kernel Display: x11 server: X.Org v: 21.1.8 driver: X: loaded: modesetting dri: nouveau gpu: nouveau resolution: 1: 1680x1050~60Hz 2: 1920x1200~60Hz API: OpenGL v: 4.3 Mesa 23.1.5 renderer: NVC1 Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter> # :) -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Thank you for sharing the results Richard! As said before the survey was live. The results preferring a rolling model are to be expected for a contributor community. That was never the strong side of Leap 15.X For me, the important part is the preferred lifecycle which shows that corespondents want 12-18 months lifecycle on the server etc. Desktop bit shorter. In an ALP-like universe (thinking of Leap Micro now) we do it exactly the opposite where we do 12 months (over two releases) for LeapMicro, while desktop users using Leap get 18 (next release + 6 months overlap). I also stay positive and optimistic when it comes to help from other teams. So far I had good experience with any timely issue. Lubos On Sat, 2023-09-02 at 10:19 +0200, Richard Brown wrote:
Hi all,
I've been looking at the results from the recent contributor survey to gauge the interest and feasibility of replacing openSUSE Leap with a new community-built offering.
For those who may not have been keeping up with the efforts, their are proposals to build two very different distributions to replace Leap:
"Linarite" - a regular old fashioned release desktop distribution, likely with a narrower package selection than we're used to with Leap unless we find significantly more contributors to be able to support everything
"Slowroll" - a derivative of Tumbleweed, built automatically as much as possible, using automation and metrics to copy packages from Tumbleweed only after certain conditions (max age, X weeks without change, etc). Basically an attempt to provide something less scary than full speed Tumbleweed.
Rather than bombard everyone with all the data, I've decided to take the approach of asking specific questions and seeing what data from the survey best helps answer that question.
--- Q1: Did the survey reach a representative sample of our contributor base?
A: The survey received 251 responses in total, 101 from people who self identified as a 'Contributor', either to the distributions or the Project more broadly. 72 identified as a distribution contributor, which is larger than the 61 people who submitted packages to Leap or Backports for the last release. Therefore I think it's clear the survey reached a broad enough audience to draw some meaningful conclusions from.
--- Q2: Between "Linarite", "Slowroll" and not replacing Leap, which is the most popular with our contributors?
A: Not replacing Leap was the most popular option when distribution contributors were asked which options would they contribute towards (39%)
Not replacing Leap/using Tumbleweed was the most popular option when distribution contributors were asked which would they use on their desktop/laptops (54%)
Those same contributors did collectively suggest that Linarite should be the direction of openSUSE (37%) and what they'd use on their servers (43%)
Q3. Between "Linarite", "Slowroll" and not replacing Leap, which is the most popular with our users?
Slowroll was the most popular option when users were asked which options they'd contribute towards (28%). Linarite was 3rd (19%) after not replacing Leap (25%)
Slowroll was also the #1 option when users were asked which option was the best direction for openSUSE (39%) and which would they use on a server (48%).
Just using Tumbleweed was also the most popular option with our users for their desktop/laptops (41%), followed by Slowroll (36%)
Linarite was not the #1 choice for our users in any of the questions asked.
Q4. Do we have enough contributors/Can we get enough contributors to make any option work?
24 distribution contributors said they would contribute to Linarite 13 said they would contribute to Slowroll 49% said they wouldn't contribute to any Leap replacement
26 users said they would contribute to Linarite 38 said they would contribute to Slowroll 53% said they wouldn't contribute to any Leap replacement
--- Some thoughts/analysis
Our users seem to overwhelmingly favour rolling releases, with 51%-64% expressing a preference for either Tumbleweed or Slowroll regardless of whether they're being asked if they'll use it for Server, Desktop, or whether they'll contribute or think it's the best direction for the project.
This preference increases when contributors are asked, with the preference ranging between 55%-71% depending on the question.
In the light of these results, it is my suggestion to the community that if we are to build something to replace Leap, then the option we should focus on is Slowroll.
It is the most popular with our users, and the option more closely aligned to what our contributors use themselves.
I also think its more important for the Leap replacement to focus on Desktop use cases, as openSUSE will also be hosting 1:1 copies of SUSE's ALP products. Those products should be awesome for folk who want Enterprise-like server distros.
Given that it seems silly to spread ourselves too thin trying to make a Leap replacement that is both a Server and Desktop OS.
That said though, I am still concerned that we do not have enough contributors to make any Leap replacement viable.
Leap has struggled even with 61 folk contributing directly to the codebase and backports/PackageHub. And this is when we've had the SLE codebase to borrow from, which dramatically reduced the work required.
Either Slowroll or Linarite would require considerably more packaging and maintenance work than Leap.
And yet, based on these survey results, we look like we're going to be replacing Leap with significantly _fewer_ contributors than we have even for Leap.
Outside of the survey, only 17 people have expressed an interest in working on a Leap replacement, and so far Slowroll and Linarite have both been one-man-shows.
Being hopeful, Slowroll does seem to be the concept that promises to convert more users into contributors.
And if we focus on Desktop-only (relying on the 1:1 ALP copies for Server) we might not need as much effort.
But I worry that we'd do more harm than good for our community to push forward towards any effort that doesn't really have much enthusiasm behind it.
The survey clearly shows a tendency for folk to believe openSUSE should do things which they themselves are not willing to contribute to.
For a Leap replacement to be viable, both to be made and then supported for years, I'm convinced we need a significant increase in folk rolling up their sleeves and working towards it.
So, I want to challenge the community with a few questions
Shall we go on with these efforts? If so, are you willing to help?
Thoughts, comments, flames all welcome
Personally, I would rather see Tumbleweed turn into Slowroll since that is something I feel lacking in the Linux community. Using only LTS kernels and slowing down the pace of which new packages hits a bit to ensure they are in a bit more stable place than cutting edge (bugs). My top priority is to have a stable computer with modern software one it, if I need to wait a month or two for a new software feature to land in distro, I gladly take that tradeoff if it gives me better stability. Lately there have been a lot of issues in Tumbleweed and especially related to the known issues with kernel 6.4, which should have been completely skipped in my opinion. Turning Tumbleweed into Slowroll would also solve the contributor/maintenance issues since it would just be replaced. An other alternative could be to just add features to Tumbleweed to support the latest LTS kernel in the repos so that it would be more easy to not get latest kernels all the time without doing a lot of custom workarounds that can lead to breakage.
On 9/11/23 05:26, Gus Fos wrote:
An other alternative could be to just add features to Tumbleweed to support the latest LTS kernel in the repos so that it would be more easy to not get latest kernels all the time without doing a lot of custom workarounds that can lead to breakage.
It would be nice if TW offered a kernel-lts package which is the latest lts release ( arch does this ). When I want to keep the LTS release I update my zypper config to keep the lts kernel version number and keep updating until there are no new versions but then once a kernel version greater than the lts version is out TW will no longer have fixes to the LTS version that come out. -- Regards, Joe
Hello, On Mon, Sep 11, 2023 at 09:40:10AM -0400, Joe Salmeri wrote:
On 9/11/23 05:26, Gus Fos wrote:
An other alternative could be to just add features to Tumbleweed to support the latest LTS kernel in the repos so that it would be more easy to not get latest kernels all the time without doing a lot of custom workarounds that can lead to breakage.
It would be nice if TW offered a kernel-lts package which is the latest lts release ( arch does this ). When I want to keep the LTS release I update my zypper config to keep the lts kernel version number and keep updating until there are no new versions but then once a kernel version greater than the lts version is out TW will no longer have fixes to the LTS version that come out.
technically there is nothing preventing shipping a LTS kernel as part of Tumbleweed. However, to do so somebody needs to maintian the kernel-lts package. Also the kernel-lts package needs to go through QA increasing the workload on the QA side. Thanks Michal
On 9/11/23 09:47, Michal Suchánek wrote:
Hello,
On Mon, Sep 11, 2023 at 09:40:10AM -0400, Joe Salmeri wrote:
On 9/11/23 05:26, Gus Fos wrote:
An other alternative could be to just add features to Tumbleweed to support the latest LTS kernel in the repos so that it would be more easy to not get latest kernels all the time without doing a lot of custom workarounds that can lead to breakage. It would be nice if TW offered a kernel-lts package which is the latest lts release ( arch does this ). When I want to keep the LTS release I update my zypper config to keep the lts kernel version number and keep updating until there are no new versions but then once a kernel version greater than the lts version is out TW will no longer have fixes to the LTS version that come out. technically there is nothing preventing shipping a LTS kernel as part of Tumbleweed.
However, to do so somebody needs to maintian the kernel-lts package. Also the kernel-lts package needs to go through QA increasing the workload on the QA side.
Thanks
Michal
I think that would be a good idea and useful to have. /etc/zypp/zypp.conf support multi kernel versions multiversion.kernels = latest,latest-1,latest-2,running However, it defaults to only 2 versions ( which the admin can change ) and that can sometimes mean that all those versions are from the same X.Y version level and that the only difference is in the 3rd digit of the version number. Sometimes when changes are released that have issues ( the kernel lockdown situation comes to mind ) it is useful to have an older kernel that is not of the same X.Y version level. I deal with those situations by modifying /etc/zypp/zypp.conf to also include a specific older kernel. This works, however, it requires manual intervention and does not handle the situation where the last version of the LTS kernel in TW is not the latest version of the LTS kernel because TW has moved to a later kernel version. -- Regards, Joe
On Tue, Sep 12, 2023 at 11:27:48AM -0400, Joe Salmeri wrote:
On 9/11/23 09:47, Michal Suchánek wrote:
Hello,
On Mon, Sep 11, 2023 at 09:40:10AM -0400, Joe Salmeri wrote:
On 9/11/23 05:26, Gus Fos wrote:
An other alternative could be to just add features to Tumbleweed to support the latest LTS kernel in the repos so that it would be more easy to not get latest kernels all the time without doing a lot of custom workarounds that can lead to breakage. It would be nice if TW offered a kernel-lts package which is the latest lts release ( arch does this ). When I want to keep the LTS release I update my zypper config to keep the lts kernel version number and keep updating until there are no new versions but then once a kernel version greater than the lts version is out TW will no longer have fixes to the LTS version that come out. technically there is nothing preventing shipping a LTS kernel as part of Tumbleweed.
However, to do so somebody needs to maintian the kernel-lts package. Also the kernel-lts package needs to go through QA increasing the workload on the QA side.
Thanks
Michal
I think that would be a good idea and useful to have.
/etc/zypp/zypp.conf support multi kernel versions
multiversion.kernels = latest,latest-1,latest-2,running
However, it defaults to only 2 versions ( which the admin can change ) and that can sometimes mean that all those versions are from the same X.Y version level and that the only difference is in the 3rd digit of the version number.
Sometimes when changes are released that have issues ( the kernel lockdown situation comes to mind ) it is useful to have an older kernel that is not of the same X.Y version level.
I deal with those situations by modifying /etc/zypp/zypp.conf to also include a specific older kernel.
This works, however, it requires manual intervention and does not handle the situation where the last version of the LTS kernel in TW is not the latest version of the LTS kernel because TW has moved to a later kernel version.
There are additional tools that you can use - add zypper lock to not install the broken version, disable the purge-kernels service to keep all kernels until your disk fills with them. Thanks Michal
On 9/12/23 11:34, Michal Suchánek wrote:
There are additional tools that you can use - add zypper lock to not install the broken version, disable the purge-kernels service to keep all kernels until your disk fills with them.
Thanks
Michal
Thanks for that info, however, I might not become aware that an issue exists until AFTER then newer kernel is installed and I don't think locking kernel-default would be a good idea. I also would not want to add more manual effort to cleanup older kernels that are no longer needed. None of those solutions or even my manually modifying /etc/zypp/zypp.conf can provide the latest LTS kernel in TW because of what I explained in my earlier reply where a LTS kernel may have newer fixes than the last LTS kernel version seen in TW because TW moved to a newer kernel version. It's not like I have had lots of kernel issues, but having the latest LTS kernel would be a quick and easy way to verify whether a problem is kernel related or not and having the kernel-lts package would make it so that if a user installed that package they would not have to worry about it being purged and it would also be the latest version of the LTS kernel that is available. Compiling and managing myself is something that I'd rather not have to do. -- Regards, Joe
On Tue, Sep 12, 2023 at 11:45:46AM -0400, Joe Salmeri wrote:
On 9/12/23 11:34, Michal Suchánek wrote:
There are additional tools that you can use - add zypper lock to not install the broken version, disable the purge-kernels service to keep all kernels until your disk fills with them.
Thanks
Michal
Thanks for that info, however, I might not become aware that an issue exists until AFTER then newer kernel is installed and I don't think locking kernel-default would be a good idea. I also would not want to add more manual effort to cleanup older kernels that are no longer needed.
The default configuration keeps a couple of earlier kernels, however. Then even after the new kernel has been installed you can go back to the previous one.
None of those solutions or even my manually modifying /etc/zypp/zypp.conf can provide the latest LTS kernel in TW because of what I explained in my earlier reply where a LTS kernel may have newer fixes than the last LTS kernel version seen in TW because TW moved to a newer kernel version.
It's not like I have had lots of kernel issues, but having the latest LTS kernel would be a quick and easy way to verify whether a problem is kernel related or not and having the kernel-lts package would make it so that if a user installed that package they would not have to worry about it being purged and it would also be the latest version of the LTS kernel that is available.
There is the Tumbleweed archive with historical kernels which you can install to test if the problem is caused by the kernel long after it has been removed from Tumbleweed if you really need to.
Compiling and managing myself is something that I'd rather not have to do.
Also so far the people maintaining the Tumbleweed kernel figured that maintaining an additional kernel is something they would rather not do, and favor fixing bugs in the one kernel Tumbleweed has. As said, if somebody wants to maintain a LTS kernel they can. Nobody has stepped up to do it, though. Thanks Michal
On 9/12/23 12:17, Michal Suchánek wrote:
On 9/12/23 11:34, Michal Suchánek wrote:
There are additional tools that you can use - add zypper lock to not install the broken version, disable the purge-kernels service to keep all kernels until your disk fills with them.
Thanks
Michal Thanks for that info, however, I might not become aware that an issue exists until AFTER then newer kernel is installed and I don't think locking kernel-default would be a good idea. I also would not want to add more manual effort to cleanup older kernels that are no longer needed. The default configuration keeps a couple of earlier kernels, however. Then even after the new kernel has been installed you can go back to the
On Tue, Sep 12, 2023 at 11:45:46AM -0400, Joe Salmeri wrote: previous one.
Right but that does not address the issue where all the installed kernel versions are from the same X.Y version, which is why I will occasionally add a specific kernel to zypp.conf to make sure that it is kept.
None of those solutions or even my manually modifying /etc/zypp/zypp.conf can provide the latest LTS kernel in TW because of what I explained in my earlier reply where a LTS kernel may have newer fixes than the last LTS kernel version seen in TW because TW moved to a newer kernel version.
It's not like I have had lots of kernel issues, but having the latest LTS kernel would be a quick and easy way to verify whether a problem is kernel related or not and having the kernel-lts package would make it so that if a user installed that package they would not have to worry about it being purged and it would also be the latest version of the LTS kernel that is available. There is the Tumbleweed archive with historical kernels which you can install to test if the problem is caused by the kernel long after it has been removed from Tumbleweed if you really need to.
Are you talking about the historical builds that are used by tumbleweed-cli located here https://download.opensuse.org/history/ That is only the last 20 published TW builds so it sounds like you are talking about some other TW archive of historical kernels. Can you please share the URL where that is located ? Thank You!
-- Regards, Joe
On Tue, Sep 12, 2023 at 12:31:35PM -0400, Joe Salmeri wrote:
On 9/12/23 12:17, Michal Suchánek wrote:
On 9/12/23 11:34, Michal Suchánek wrote:
There are additional tools that you can use - add zypper lock to not install the broken version, disable the purge-kernels service to keep all kernels until your disk fills with them.
Thanks
Michal Thanks for that info, however, I might not become aware that an issue exists until AFTER then newer kernel is installed and I don't think locking kernel-default would be a good idea. I also would not want to add more manual effort to cleanup older kernels that are no longer needed. The default configuration keeps a couple of earlier kernels, however. Then even after the new kernel has been installed you can go back to the
On Tue, Sep 12, 2023 at 11:45:46AM -0400, Joe Salmeri wrote: previous one.
Right but that does not address the issue where all the installed kernel versions are from the same X.Y version, which is why I will occasionally add a specific kernel to zypp.conf to make sure that it is kept.
It does address the problem of keeping the previous version, whether it's the same X.Y version or not does not matter. When you find a problem you can go to the earlier version with which the problem was not observed.
None of those solutions or even my manually modifying /etc/zypp/zypp.conf can provide the latest LTS kernel in TW because of what I explained in my earlier reply where a LTS kernel may have newer fixes than the last LTS kernel version seen in TW because TW moved to a newer kernel version.
It's not like I have had lots of kernel issues, but having the latest LTS kernel would be a quick and easy way to verify whether a problem is kernel related or not and having the kernel-lts package would make it so that if a user installed that package they would not have to worry about it being purged and it would also be the latest version of the LTS kernel that is available. There is the Tumbleweed archive with historical kernels which you can install to test if the problem is caused by the kernel long after it has been removed from Tumbleweed if you really need to.
Are you talking about the historical builds that are used by tumbleweed-cli located here
Which have 6.4 kernels while Tumbleweed has 6.5 Also see https://download.opensuse.org/repositories/home:/tiwai:/kernel:/ Thanks Michal
On 9/12/23 12:41, Michal Suchánek wrote:
On 9/12/23 12:17, Michal Suchánek wrote:
On 9/12/23 11:34, Michal Suchánek wrote:
There are additional tools that you can use - add zypper lock to not install the broken version, disable the purge-kernels service to keep all kernels until your disk fills with them.
Thanks
Michal Thanks for that info, however, I might not become aware that an issue exists until AFTER then newer kernel is installed and I don't think locking kernel-default would be a good idea. I also would not want to add more manual effort to cleanup older kernels that are no longer needed. The default configuration keeps a couple of earlier kernels, however. Then even after the new kernel has been installed you can go back to the
On Tue, Sep 12, 2023 at 11:45:46AM -0400, Joe Salmeri wrote: previous one. Right but that does not address the issue where all the installed kernel versions are from the same X.Y version, which is why I will occasionally add a specific kernel to zypp.conf to make sure that it is kept. It does address the problem of keeping the previous version, whether it's the same X.Y version or not does not matter. When you find a
On Tue, Sep 12, 2023 at 12:31:35PM -0400, Joe Salmeri wrote: problem you can go to the earlier version with which the problem was not observed.
It DOES matter if it is the same X.Y version because if one does frequent TW updates they could easily end up with all the kernel versions they have installed being the same X.Y version which has the problem. That as one of my key points as to why the LTS would be useful :-) to have for those cases. Fortunately the tumbleweed-cli history folders have the last 20 builds so most likely a version that is not from the same X.Y version could be found. Yes, I could lock the kernel or modify zypp.conf as I have been doing but the idea was that with the LTS version it would all be automatic. There does not seem to be any interest in this or anyone to maintain it so I'll just keep modifying zypp.conf multiversion when I need to keep one around. Not a major issue, just seemed like a nice feature that arch has over TW.
None of those solutions or even my manually modifying /etc/zypp/zypp.conf can provide the latest LTS kernel in TW because of what I explained in my earlier reply where a LTS kernel may have newer fixes than the last LTS kernel version seen in TW because TW moved to a newer kernel version.
It's not like I have had lots of kernel issues, but having the latest LTS kernel would be a quick and easy way to verify whether a problem is kernel related or not and having the kernel-lts package would make it so that if a user installed that package they would not have to worry about it being purged and it would also be the latest version of the LTS kernel that is available. There is the Tumbleweed archive with historical kernels which you can install to test if the problem is caused by the kernel long after it has been removed from Tumbleweed if you really need to. Are you talking about the historical builds that are used by tumbleweed-cli located here
https://download.opensuse.org/history/ Which have 6.4 kernels while Tumbleweed has 6.5
Also see https://download.opensuse.org/repositories/home:/tiwai:/kernel:/ Thanks very much for that link, I see that there are lots of kernel versions available there.
-- Regards, Joe
On Tue, Sep 12, 2023 at 12:54:52PM -0400, Joe Salmeri wrote:
On 9/12/23 12:41, Michal Suchánek wrote:
On 9/12/23 12:17, Michal Suchánek wrote:
On 9/12/23 11:34, Michal Suchánek wrote:
There are additional tools that you can use - add zypper lock to not install the broken version, disable the purge-kernels service to keep all kernels until your disk fills with them.
Thanks
Michal Thanks for that info, however, I might not become aware that an issue exists until AFTER then newer kernel is installed and I don't think locking kernel-default would be a good idea. I also would not want to add more manual effort to cleanup older kernels that are no longer needed. The default configuration keeps a couple of earlier kernels, however. Then even after the new kernel has been installed you can go back to the
On Tue, Sep 12, 2023 at 11:45:46AM -0400, Joe Salmeri wrote: previous one. Right but that does not address the issue where all the installed kernel versions are from the same X.Y version, which is why I will occasionally add a specific kernel to zypp.conf to make sure that it is kept. It does address the problem of keeping the previous version, whether it's the same X.Y version or not does not matter. When you find a
On Tue, Sep 12, 2023 at 12:31:35PM -0400, Joe Salmeri wrote: problem you can go to the earlier version with which the problem was not observed.
It DOES matter if it is the same X.Y version because if one does frequent TW updates they could easily end up with all the kernel versions they have installed being the same X.Y version which has the problem.
The version number is overrated - sometimes a problem is introduced by major version update, sometimes by stable release, sometimes by configuration change. If you missed the problem for long enough that the good kernel is gone with multiversion it's unlikely to be so critical that you would not be able to look for the older versions online. There is no guarantee that a kernel with different X.Y version would not have the problem - it depends very much on the specifics. Thanks Michal
On 9/12/23 13:05, Michal Suchánek wrote:
On Tue, Sep 12, 2023 at 12:54:52PM -0400, Joe Salmeri wrote:
It DOES matter if it is the same X.Y version because if one does frequent TW updates they could easily end up with all the kernel versions they have installed being the same X.Y version which has the problem. The version number is overrated - sometimes a problem is introduced by major version update, sometimes by stable release, sometimes by configuration change.
If you missed the problem for long enough that the good kernel is gone with multiversion it's unlikely to be so critical that you would not be able to look for the older versions online.
There is no guarantee that a kernel with different X.Y version would not have the problem - it depends very much on the specifics.
Thanks, with the 20 history versions, the new URL you provided with older kernels, and my flagging a kernel to keep in zypp.conf, that should give me all the options I need. Regards, Joe
Joe Salmeri composed on 2023-09-12 11:45 (UTC-0400):
Michal Suchánek wrote:
There are additional tools that you can use - add zypper lock to not install the broken version, disable the purge-kernels service to keep all kernels until your disk fills with them.
Thanks for that info, however, I might not become aware that an issue exists until AFTER then newer kernel is installed and I don't think locking kernel-default would be a good idea.
Why? # zypper ll | grep kern 25 | kernel-az* | package | (any) | 26 | kernel-de* | package | (any) | 27 | kernel-kv* | package | (any) | 28 | kernel-pree* | package | (any) | 29 | kernel-rt* | package | (any) | 30 | kernel-sy* | package | (any) | # All my Leap installations have the above. My TWs only lock kernel-de*. This general practice is well over a decade old. I decide when is the right time another kernel is appropriate to install. That doesn't happen unless I expect a soon reboot.
I also would not want to add more manual effort to cleanup older kernels that are no longer needed.
Trivial, and only occasional, unless disk space is too precious. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Tue, Sep 12, 2023 at 1:57 PM Joe Salmeri <jmscdba@gmail.com> wrote:
On 9/11/23 09:47, Michal Suchánek wrote:
Hello,
On Mon, Sep 11, 2023 at 09:40:10AM -0400, Joe Salmeri wrote:
On 9/11/23 05:26, Gus Fos wrote:
An other alternative could be to just add features to Tumbleweed to support the latest LTS kernel in the repos so that it would be more easy to not get latest kernels all the time without doing a lot of custom workarounds that can lead to breakage. It would be nice if TW offered a kernel-lts package which is the latest lts release ( arch does this ). When I want to keep the LTS release I update my zypper config to keep the lts kernel version number and keep updating until there are no new versions but then once a kernel version greater than the lts version is out TW will no longer have fixes to the LTS version that come out. technically there is nothing preventing shipping a LTS kernel as part of Tumbleweed.
However, to do so somebody needs to maintian the kernel-lts package. Also the kernel-lts package needs to go through QA increasing the workload on the QA side.
Thanks
Michal
I think that would be a good idea and useful to have.
/etc/zypp/zypp.conf support multi kernel versions
multiversion.kernels = latest,latest-1,latest-2,running
However, it defaults to only 2 versions ( which the admin can change ) and that can sometimes mean that all those versions are from the same X.Y version level and that the only difference is in the 3rd digit of the version number.
Sometimes when changes are released that have issues ( the kernel lockdown situation comes to mind ) it is useful to have an older kernel that is not of the same X.Y version level.
I deal with those situations by modifying /etc/zypp/zypp.conf to also include a specific older kernel.
This works, however, it requires manual intervention and does not handle the situation where the last version of the LTS kernel in TW is not the latest version of the LTS kernel because TW has moved to a later kernel version.
There is also the problem that kernel rebuilds (which can and do change/break things) do not get parallel installed with zypper. They get upgraded in-place, instead. So we don't truly do this feature correctly either. This is much more obvious when using DNF because DNF doesn't allow you to remove or obsolete the running kernel by default. -- 真実はいつも一つ！/ Always, there's only one truth!
On 9/13/23 15:55, Neal Gompa wrote:
On Tue, Sep 12, 2023 at 1:57 PM Joe Salmeri<jmscdba@gmail.com> wrote:
I think that would be a good idea and useful to have.
/etc/zypp/zypp.conf support multi kernel versions
multiversion.kernels = latest,latest-1,latest-2,running
However, it defaults to only 2 versions ( which the admin can change ) and that can sometimes mean that all those versions are from the same X.Y version level and that the only difference is in the 3rd digit of the version number.
Sometimes when changes are released that have issues ( the kernel lockdown situation comes to mind ) it is useful to have an older kernel that is not of the same X.Y version level.
I deal with those situations by modifying /etc/zypp/zypp.conf to also include a specific older kernel.
This works, however, it requires manual intervention and does not handle the situation where the last version of the LTS kernel in TW is not the latest version of the LTS kernel because TW has moved to a later kernel version.
There is also the problem that kernel rebuilds (which can and do change/break things) do not get parallel installed with zypper. They get upgraded in-place, instead. So we don't truly do this feature correctly either.
This is much more obvious when using DNF because DNF doesn't allow you to remove or obsolete the running kernel by default.
Not sure what you mean. I have multiple kernels installed including the last LTS version that was in TW. drwxr-xr-x 1 root root 124 Sep 11 12:14 . dr-xr-xr-x 1 root root 19K Sep 11 15:05 .. drwxr-xr-x 1 root root 652 Mar 19 15:50 6.1.12-1-default drwxr-xr-x 1 root root 652 Sep 11 12:17 6.4.12-1-default drwxr-xr-x 1 root root 652 Aug 2 10:58 6.4.6-1-default drwxr-xr-x 1 root root 652 Aug 10 14:36 6.4.8-1-default Regards, Joe
On Wed, Sep 13, 2023 at 4:09 PM Joe Salmeri <jmscdba@gmail.com> wrote:
On 9/13/23 15:55, Neal Gompa wrote:
On Tue, Sep 12, 2023 at 1:57 PM Joe Salmeri <jmscdba@gmail.com> wrote:
I think that would be a good idea and useful to have.
/etc/zypp/zypp.conf support multi kernel versions
multiversion.kernels = latest,latest-1,latest-2,running
However, it defaults to only 2 versions ( which the admin can change ) and that can sometimes mean that all those versions are from the same X.Y version level and that the only difference is in the 3rd digit of the version number.
Sometimes when changes are released that have issues ( the kernel lockdown situation comes to mind ) it is useful to have an older kernel that is not of the same X.Y version level.
I deal with those situations by modifying /etc/zypp/zypp.conf to also include a specific older kernel.
This works, however, it requires manual intervention and does not handle the situation where the last version of the LTS kernel in TW is not the latest version of the LTS kernel because TW has moved to a later kernel version.
There is also the problem that kernel rebuilds (which can and do change/break things) do not get parallel installed with zypper. They get upgraded in-place, instead. So we don't truly do this feature correctly either.
This is much more obvious when using DNF because DNF doesn't allow you to remove or obsolete the running kernel by default.
Not sure what you mean. I have multiple kernels installed including the last LTS version that was in TW.
drwxr-xr-x 1 root root 124 Sep 11 12:14 . dr-xr-xr-x 1 root root 19K Sep 11 15:05 .. drwxr-xr-x 1 root root 652 Mar 19 15:50 6.1.12-1-default drwxr-xr-x 1 root root 652 Sep 11 12:17 6.4.12-1-default drwxr-xr-x 1 root root 652 Aug 2 10:58 6.4.6-1-default drwxr-xr-x 1 root root 652 Aug 10 14:36 6.4.8-1-default
But you don't have 6.4.12-1.1 or 6.4.12-1.2. The build counter is chopped off and finagled to make it look like it's not there. Especially when compiler upgrades and such occur (which are represented by increasing the build counter), this can be annoying. -- 真実はいつも一つ！/ Always, there's only one truth!
On 9/13/23 16:15, Neal Gompa wrote:
On Wed, Sep 13, 2023 at 4:09 PM Joe Salmeri <jmscdba@gmail.com> wrote:
On 9/13/23 15:55, Neal Gompa wrote:
On Tue, Sep 12, 2023 at 1:57 PM Joe Salmeri <jmscdba@gmail.com> wrote:
I think that would be a good idea and useful to have.
/etc/zypp/zypp.conf support multi kernel versions
multiversion.kernels = latest,latest-1,latest-2,running
However, it defaults to only 2 versions ( which the admin can change ) and that can sometimes mean that all those versions are from the same X.Y version level and that the only difference is in the 3rd digit of the version number.
Sometimes when changes are released that have issues ( the kernel lockdown situation comes to mind ) it is useful to have an older kernel that is not of the same X.Y version level.
I deal with those situations by modifying /etc/zypp/zypp.conf to also include a specific older kernel.
This works, however, it requires manual intervention and does not handle the situation where the last version of the LTS kernel in TW is not the latest version of the LTS kernel because TW has moved to a later kernel version.
There is also the problem that kernel rebuilds (which can and do change/break things) do not get parallel installed with zypper. They get upgraded in-place, instead. So we don't truly do this feature correctly either.
This is much more obvious when using DNF because DNF doesn't allow you to remove or obsolete the running kernel by default.
Not sure what you mean. I have multiple kernels installed including the last LTS version that was in TW.
drwxr-xr-x 1 root root 124 Sep 11 12:14 . dr-xr-xr-x 1 root root 19K Sep 11 15:05 .. drwxr-xr-x 1 root root 652 Mar 19 15:50 6.1.12-1-default drwxr-xr-x 1 root root 652 Sep 11 12:17 6.4.12-1-default drwxr-xr-x 1 root root 652 Aug 2 10:58 6.4.6-1-default drwxr-xr-x 1 root root 652 Aug 10 14:36 6.4.8-1-default
But you don't have 6.4.12-1.1 or 6.4.12-1.2. The build counter is chopped off and finagled to make it look like it's not there.
Especially when compiler upgrades and such occur (which are represented by increasing the build counter), this can be annoying.
More likely it is because I don't update to ever new build that is published and therefore when I do update it is already to a newer x.y.z version. Regards, Joe
On Wed, 13 Sep 2023 16:15:01 -0400, Neal Gompa <ngompa13@gmail.com> wrote:
On Wed, Sep 13, 2023 at 4:09 PM Joe Salmeri <jmscdba@gmail.com> wrote:
Not sure what you mean. I have multiple kernels installed including the last LTS version that was in TW. drwxr-xr-x 1 root root 652 Mar 19 15:50 6.1.12-1-default drwxr-xr-x 1 root root 652 Sep 11 12:17 6.4.12-1-default drwxr-xr-x 1 root root 652 Aug 2 10:58 6.4.6-1-default drwxr-xr-x 1 root root 652 Aug 10 14:36 6.4.8-1-default
But you don't have 6.4.12-1.1 or 6.4.12-1.2. The build counter is chopped off and finagled to make it look like it's not there.
So the tail end ".[n]" of the version is replaced with "-default", no matter the value of [n]? I hate when that happens. ;-)
Especially when compiler upgrades and such occur (which are represented by increasing the build counter), this can be annoying.
-- Robert Webb
On Wed, Sep 13, 2023 at 04:15:01PM -0400, Neal Gompa wrote:
On Wed, Sep 13, 2023 at 4:09 PM Joe Salmeri <jmscdba@gmail.com> wrote:
On 9/13/23 15:55, Neal Gompa wrote:
On Tue, Sep 12, 2023 at 1:57 PM Joe Salmeri <jmscdba@gmail.com> wrote:
I think that would be a good idea and useful to have.
/etc/zypp/zypp.conf support multi kernel versions
multiversion.kernels = latest,latest-1,latest-2,running
However, it defaults to only 2 versions ( which the admin can change ) and that can sometimes mean that all those versions are from the same X.Y version level and that the only difference is in the 3rd digit of the version number.
Sometimes when changes are released that have issues ( the kernel lockdown situation comes to mind ) it is useful to have an older kernel that is not of the same X.Y version level.
I deal with those situations by modifying /etc/zypp/zypp.conf to also include a specific older kernel.
This works, however, it requires manual intervention and does not handle the situation where the last version of the LTS kernel in TW is not the latest version of the LTS kernel because TW has moved to a later kernel version.
There is also the problem that kernel rebuilds (which can and do change/break things) do not get parallel installed with zypper. They get upgraded in-place, instead. So we don't truly do this feature correctly either.
This is much more obvious when using DNF because DNF doesn't allow you to remove or obsolete the running kernel by default.
Not sure what you mean. I have multiple kernels installed including the last LTS version that was in TW.
drwxr-xr-x 1 root root 124 Sep 11 12:14 . dr-xr-xr-x 1 root root 19K Sep 11 15:05 .. drwxr-xr-x 1 root root 652 Mar 19 15:50 6.1.12-1-default drwxr-xr-x 1 root root 652 Sep 11 12:17 6.4.12-1-default drwxr-xr-x 1 root root 652 Aug 2 10:58 6.4.6-1-default drwxr-xr-x 1 root root 652 Aug 10 14:36 6.4.8-1-default
But you don't have 6.4.12-1.1 or 6.4.12-1.2. The build counter is chopped off and finagled to make it look like it's not there.
Especially when compiler upgrades and such occur (which are represented by increasing the build counter), this can be annoying.
Besides compiler upgrades the OBS may decide to do spurious rebuild for no apparent reason, or the build may fail because the worker goes down, and is retriggered. And then we have multiple packages like kernel-source and kernel-default that need to match, and that is the reason for chopping off the build counter. That's not ideal for Factory that does get major compiler upgrades. Still spurious rebuilds are considered more of a problem than major compiler upgrades so far. Thanks Michal
On Monday 2023-09-11 11:26, Gus Fos wrote:
Personally, I would rather see Tumbleweed turn into Slowroll
That is not going to change anything really. The package maintainer decides when to make an update, and to what version. E.g. cdecl gets updated every milestone, but vulkan-loader is only updated every ~10 milestones. The determination can and does happen independently of the target [Tumbleweed/Slowroll/Leap].
if I need to wait a month or two for a new software feature to land in distro, I gladly take that tradeoff if it gives me better stability.
Delaying the availability to people only means people see the bugs (which exist in any case) belatedly: Given 60000 TW users and a .01% daily chance to hit some bug, within ~12 days, the chance for a bug report to come about has passed 50%. (says some web calculator - anyone with powers in statitics should cross-check). If you take away 80% of TW users by moving them to Slowroll (full 30d delivery delay implied), time to 50% existence chance is ~36 days I think. That new vs. stable trade isn't performed at 1:1, nor linearly, and there is something to be said about diminishing returns.
On 11. 09. 23, 11:26, Gus Fos wrote:
Personally, I would rather see Tumbleweed turn into Slowroll
I would not.
Lately there have been a lot of issues in Tumbleweed and especially related to the known issues with kernel 6.4,
What known issues?
which should have been completely skipped in my opinion.
If we skipped 6.4, you would see the issues in 6.5. What sense does it make?
An other alternative could be to just add features to Tumbleweed to support the latest LTS kernel in the repos so that it would be more easy to not get latest kernels all the time without doing a lot of custom workarounds that can lead to breakage.
Everyone is open to maintain the kernel and fix the bugs ;). regards, -- js suse labs
On Wed, 2023-09-13 at 11:03 +0200, Jiri Slaby wrote:
On 11. 09. 23, 11:26, Gus Fos wrote:
Personally, I would rather see Tumbleweed turn into Slowroll
I would not.
I also would not. I am academically interested in Slowroll and am curious as to whether the approach brings any practical benefits at all. I am open to the possibility that it might, but I also suspect that it will not. The best maintained code is always going to be the one that's best maintained, most recently maintained, most actively maintained, and that's always going to be Tumbleweed.
which should have been completely skipped in my opinion.
If we skipped 6.4, you would see the issues in 6.5. What sense does it make?
Exactly, problems will always occur, software development is never perfect. But Tumbleweed is continually the platform with the shortest time window between issues found and issues fixed. That makes it the best-working platform we have most of the time, and when it isn't any disruption is for a minimal time easily coasted by rollbacks. Slowroll may be less scary than Tumbleweed but I think it's inevitable that it will have issues just like any distribution, and those issues will be harder to fix and hang around for longer because of its slower- by-design model.
An other alternative could be to just add features to Tumbleweed to support the latest LTS kernel in the repos so that it would be more easy to not get latest kernels all the time without doing a lot of custom workarounds that can lead to breakage.
Everyone is open to maintain the kernel and fix the bugs ;).
-- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
On 9/13/23 05:03, Jiri Slaby wrote:
On 11. 09. 23, 11:26, Gus Fos wrote:
Personally, I would rather see Tumbleweed turn into Slowroll
I would not.
Lately there have been a lot of issues in Tumbleweed and especially related to the known issues with kernel 6.4,
What known issues?
which should have been completely skipped in my opinion.
If we skipped 6.4, you would see the issues in 6.5. What sense does it make?
Hi Jiri, Just an FYI, that VMWare is broken with the 6.5 kernel as the modules will no longer compile. VMWare has not come out with a new version that fixes the compile issue and switching from the vmware provided modules to 3rd party versions at https://github.com/mkubecek/vmware-host-modules also does not fix the issue ( It did fix issues with the 6.4 kernels ). Regards, Joe
On 13. 09. 23, 21:34, Joe Salmeri wrote:
On 9/13/23 05:03, Jiri Slaby wrote:
On 11. 09. 23, 11:26, Gus Fos wrote:
Personally, I would rather see Tumbleweed turn into Slowroll
I would not.
Lately there have been a lot of issues in Tumbleweed and especially related to the known issues with kernel 6.4,
What known issues?
which should have been completely skipped in my opinion.
If we skipped 6.4, you would see the issues in 6.5. What sense does it make?
Hi Jiri,
Just an FYI, that VMWare is broken with the 6.5 kernel as the modules will no longer compile.
Hi, please talk to VMWare. Before every release, they have enough weeks to fix their modules. If they are unable to do so, you still can use something which keeps up and is opensource (like qemu). thanks, -- js suse labs
participants (23)
-
Bernhard M. Wiedemann -
Carlos E. R. -
Chuck Payne -
dieter -
Dominik George -
Enrico Belleri -
Felix Miata -
Fritz Hudnut -
Gus Fos -
Jan Engelhardt -
Jiri Slaby -
Joe Salmeri -
John Kizer -
Larry Len Rainey -
Lubos Kocman -
Luna Jernberg -
Malcolm -
Matěj Cepl -
Michal Suchánek -
Neal Gompa -
Richard Brown -
Robert Webb -
Simon Lees