On Fri, 2022-06-24 at 10:27 +0200, Axel Braun wrote:
Dear Geekos,
those who joined the openSUSE conference got aware that we have a completely new approach (ALP) on the desk.
But until this flies, we need to make sure that Leap stays attractive for the openSUSE community. In other words - Leap 15.5 needs to receive updates and new features - updated versions of Rust and Python, just to mention two burning topics, as both versions shipped as default in current Leap are already EOL.
We understand that SLE15-SP5, the basis of Leap 15.5, will be a 'no feature' release.
And this is exactly the problem. We need to update the application layer like in the development model before Closing-the-Leap-Gap, ideally from Tumbleweed.
In the release engineering meeting on 15.06. [1] this was discussed (briefly). A potential solution could be to collect these updates in a repo like openSUSE:Leap:15.5
The intention of this mail is to get the discussion about a solution started, in order to make Leap 15.5 great product, before ALP flies.
- Is a separate repo for application updates a feasible approach?
Application updates, yes. But core library updates? Probably not - and your examples above of updated versions of Rust and Python would be core library updates. And replacing something used throughout the distribution like Python would require so many other python-dependant applications to be rebuilt, that the result would not be 'Leap', nor be remotely compatable with SLE. And if we don't update Python as the core library but instead have a second Python that needs to be installed alongside. Then I believe we'd need to build and maintain all of our Python modules in addition alongside. I would be surprised if we can find the contributors to do that, I imagine it is a lot of work. and even if we do, anyone consuming that secondary Python would need to modify their software to use that Python and not the system Python. I imagine all the upstreams/maintainers involved would not appreciate that extra work. Especially when that extra work would ultimately be for a lifespan of less than 2 years and would not be relevant/transferable into any future openSUSE ALP development. Regards, Richard