LWN: Comments on "Replacing openSUSE Leap"

Where is the economic model for OpenSuse?

roblucid — Sat, 23 Sep 2023 10:24:00 +0000

SuSE is a biz, desktop enthusiast users like freebies. OpenSuSE was the community free unsupported version of SLES.
As such OpenSuSE is reliant on facilities provided by the company providing the distro, justified as a free intro into SuSE.
SuSE built many very flexible tools that allowed tailored install image creation and building packages for distribution for other distros.

The article is about the impact of SLES ceasing in favour of apparently data centre & edge commercial deployments, that left Leap without the SLES base that it was layered on.

Replacing openSUSE Leap

roblucid — Sat, 23 Sep 2023 09:57:26 +0000

Basically Wol Tumbleweed is the Fastroll where distro package developers request their package updates to be made available to more users.
The SuSE development repository could have "in progress" broken packages checked in and had to be stabilised and fixed prior to release.

It's more like Debian unstable Sid, where package maintainers submitting updates are aware that there's a vocal user base whose systems they could be breaking. For packages to go into Tumbleweed, they might be batched together with dependencie protecting against inclusion with incompatible libraries.

Replacing openSUSE Leap

roblucid — Sat, 23 Sep 2023 09:40:43 +0000

When Tumbleweed was first launched, I switched to it to have the new features & fixes out from upstream on the desktop in a timely manner. It was not uncommon to install packages you cared about compiled direct from upstream and if you run windows, you receive 3rd party updates direct from the developers without it causing continual chaos. I figured out how to gain the multi-media capabilities provided from 3rd party repositories that GKH had excluded and thought was not possible with Tumbleweed as he actually underestimated the features and flexibility of the SuSE package management system.

Previously I had to bastardise my base release by including a growing number of repositories, that included distro specific changes to upstream development. At times I was hit by regressions, discovered far too late; developers re-developing do have a tendency to deliver partial implementations and years later when their code eventaually reaches a distro they'll reject bug reports about something they thought they could drop and now the code is cold and unfamiliar, defective by design because it's something not used by developer peer groups. That lead to me having to replace hardware on 2 occasions.

Tumbleweed has no mechanism to say it's "stable" and snap shot worthy, freezing a state just creates a load of maintenance work deciding what fixes have to be patched into the base code. Nobody upstream is testing vs your distro, you'd be creating flag days for switches that needs lots of people to test. In my experience, Tumbleweed was NOT breaking the whole time, contrary to the fears of frozen release advocates. Packages have to be tested
against something for something to be included, so you have both upstream and a distro package contributor testing the update.

Slowroll is a far better idea, lets Tumbleweed users demand fixes if an engineer releases a broken package into it, while avoiding admin & work creation schemes of curating, what is supposed to be an improved code base by the work of developers and QA. Anybody who tracks Tumbleweed and uses the applications or uses upstream packages and reports bugs is contributing to the correctness of Slowroll.

SLE going away, also the SLE Desktop?

ber — Tue, 12 Sep 2023 06:42:31 +0000

Does this mean that https://www.suse.com/products/desktop/ will be discontinued?

Where is the economic model for OpenSuse?

ber — Mon, 11 Sep 2023 14:59:08 +0000

A central challenge is to get enough person-power behind a desktop oriented approach for OpenSUSE.

It seems SUSE is not interested in offering something like this. And just relying on volunteers is creating the resource challenges and this will only get worse.

Replacing openSUSE Leap

bmwiedemann — Mon, 11 Sep 2023 11:26:08 +0000

https://en.opensuse.org/openSUSE:Slowroll works on the source level. So it does not matter that the faster Tumbleweed compiled it with a newer library as long as it still builds with the older library in Slowroll. Important stuff will be tested by openQA to ensure it remains working.

Occasionally there will be source-level incompatibilities (e.g. using a new rpm macro) where we either have to spend the time to resolve it or bump the base repo to the latest Tumbleweed to have everything in sync again - at the expense of more updates for users.

Replacing openSUSE Leap

bmwiedemann — Mon, 11 Sep 2023 11:16:01 +0000

We had that model as openSUSE releases before Leap was based on SLE sources. The main trouble was that we wanted to avoid version upgrades for stability and that meant doing backports of fixes which takes quite some effort for 15000 packages.
There are also security fixes in newer versions that never get a CVE because nobody realized that "refactor foo" elimitated a severe vulnerability.

Replacing openSUSE Leap

Conan_Kudo — Sun, 10 Sep 2023 20:56:29 +0000

That is what Slowroll is.

Replacing openSUSE Leap

smoogen — Fri, 08 Sep 2023 15:16:07 +0000

I have seen this proposed in the past for other distros, but the problems that come up are:
1. What does 'stabilized' mean? [You usually end up with people spending more time arguing over what that means and who gets to judge it than people actually testing for said 'stability'.]
2. Who is going to do the testing work to say something is stable?
3. What gets put into the pile of 'we care it is stable' and 'we don't care it is stable'?
4. Who is going to possibly backport fixes which need to be done versus boiling the ocean for a complete upgrade of a software stack.

Usually the discussions over this get incredibly heated because most of the items are subjective decision points. Most of those heated discussions come up in other areas, and when you have a small number of participants who have known each other for decades.. it is better to just avoid the unresolvable and present what might be generally accepted.

Replacing openSUSE Leap

Wol — Fri, 08 Sep 2023 10:52:23 +0000

Given that it's a desktop distro, and they often have stuff that's not in the base distro, why not create a FastRoll repository.

Basically, its primary purpose is (a) to be empty as much as possible, and (b) to fast-track packages from Tumbleweed into Slowroll. Basically, all urgent fixes go in there, and you hopefully have enough people using it to know that problems are likely to surface quickly.

Yes, it's a little more work, but you could even make it part of your release strategy - all planned upgrades dump a group of related packages into FastRoll, test them for a week or two to look for problems, and then promote them to Slowroll. Any packages that spend more than said week or two in FastRoll get dumped out as "not ready for release".

Cheers,
Wol

Replacing openSUSE Leap

eru — Fri, 08 Sep 2023 09:45:10 +0000

What about a Leap that is a "stabilized" snapshot of Tumbleweed, taken every 6 - 12 months or so? Looks like that option was not on the table.

Replacing openSUSE Leap

smcv — Fri, 08 Sep 2023 08:56:50 +0000

> Packages would move from Tumbleweed to Slowroll when they have shown, over a period of time, that they are unlikely to introduce new problems

Prior art for this: Debian 'testing' (the branch where the next stable Debian release is prepared) has this design, with 'unstable' (the branch that maintainers upload new packages into) as the equivalent of Tumbleweed. That's great, up to a point...

> would require a lot of work that is not being done (by the openSUSE community, at least) now
...
> 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

... but unfortunately, Debian also has prior art for this problem: the major problem with using 'testing' as a desktop distribution is that it has no direct security support. CVE fixes and other targeted bug fixes are done in 'unstable' and migrate to 'testing' in the same way as any other change, but if there is a big transition happening in unstable, that migration can be delayed by several days or even weeks by what is happening in adjacent packages (if the fixed version of a package with a CVE gets compiled against a new library that isn't ready to migrate due to some unrelated regression, then the fixed version often can't migrate either).

In theory maintainers can do urgent targeted bug fixes by uploading to 'testing-proposed-updates', but using t-p-u requires release team approval which they are cautious about giving, because it gets no real-world testing - there is basically nobody who runs packages in that suite, so any regressions in those packages are only discovered when they get into 'testing', by which time it's too late to avoid those regressions being seen by end users.

I hope openSUSE can overcome the resource problems with this (and if they can, their approaches will likely be interesting for Debian too). Good luck!