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