On 2023-05-08 13:06, Simon Lees wrote:
On 5/8/23 18:28, Richard Brown wrote:
On 2023-05-05 14:44, Lubos Kocman via openSUSE Factory wrote:
I understand the situation changed (desktop etc) but my POV doesn't change as I know we can rely on our existing "Leap crew", including Marcus, Max, Fabian, Oliver, Santi, Jose, Martin, Jacob, Mauricio, Simon, Bernhard, Georg, Christian, Frank, Lukas, Guillaume, Sarah, Dirk, $YOU,... I can't even recall how many dozens of recognitions I sent for 15.3, 15.4 :) People like to jump on board and help where they can once the foundation is set.
The biggest problem I see right now is that of your existing "Leap crew" of 19 names, at most we can say 5 of them have responded to show any interest in this new distribution - Yourself, Marcus, Max, Maurizio and Simon.
In addition we currently have 5 new names who've so far stepped up
But of those 5 new names, 2 of them have no packaging/distro building experience and will need extra mentoring to get there.
And so, as it stands at time of writing, we currently have, at best, half the people willing to take a shot at solving all the problems we'll need to face building against this new codebase.
and facing this very small team, we have a challenge far bigger than just building another Leap version, because this will be a brand new Product, build and bootstrapped from scratch, based on a brand new codebase which has only recently been built and bootstrapped from scratch.
One of the things I found in the setup I did is there wasn't actually much "Bootstrapping" required, just by inheriting the "SUSE:ALP" Repo all the really hard work is done atleast from a bootstrapping packages perspective Things like openQA will obviously take more.
The fact it is a new codebase and is so close to current Tumbleweed is also a big advantage over the work required for current Leap 15.4/5 because you can currently take a package from tumbleweed and be reasonably certain it'll build and function.
Seriously? I find that very surprising, my evaluation is we have huge hurdles to tackle. Because lets assume we're going to follow the ALP installation methods of Agama There we lose the whole concept of 'System Roles' - so no more offering Server, KDE Desktop, GNOME Desktop, etc If (as I'm assuming at the moment) the goal is a Leap-a-like, someone is going to have to figure out a way of mapping what Leap users would expect to Agama's 'Products' concept, and figure how to implement that in a way that works with Agama - or extend Agama to work in a way we want. And I assume any additional requirements we have here are unlikely to be tackled by the existing Agama team any time soon - they have enough on their plate. So we need to be prepared to do stuff ourselves in the first instance. It's also worth keeping in mind Maintenance's clear requirement that we only produce one 'Product' else risk exceeding their maintenance resources, when Agama seems to typically use 'Products' like YaST would offer System Roles. Agama has some pretty interesting handling of patterns compared to YaST, maybe that would be a way out, but that would likely require a HUGE change to how we do patterns compared to Tumbleweed and old Leap. Figuring out with path forward there is a huge task unfair to put on any single individual, as it will doubtlessly require "buy-in" from everyone actually building the resulting distro to all pull together and handle the consequences of each path. Or, alternatively, lets assume the Leap-alike doesn't use Agama and sticks with YaST That wouldn't actually reduce the work required. Creating new installation images and defining everything that needs to be defined for a YaST driven installation routine is an absolute pain that takes weeks in my experience And that divergence in direction from what SUSE is doing will mean folk will need to step up and be prepared to take on a lot more work around installation-images, skelcd-control files, and YaST, which was historically handled by the YaST team. There is no 'low cost' way forward I see. This is a new distribution in a new environment for both openSUSE and SUSE, and we need everyone to be well aware of that and willing to do the work the communities chosen path requires. Bootstrapping the packages might be easy, but actually producing anything that would be remotely usable by anyone is a big task with lots of unknowns we need willing people to tackle. In both cases we do not really have that much available in Tumbleweed or Leap, or even SUSE ALP, to really help us get this off the ground. A lot of it will be jumping into the unknown. And these are things can't be just tackled in isolation or even sequentially, as changes to how repositories are structured and such are intimately linked to how we'd build installation-images, Agama images, or whatever we want to offer for people to install this. And how repositories are structured could end up being hugely different given the new way of building things. Hence my view that the only way forward is really finding a core group willing to architect and get building this new distro from the ground up, rather than just assuming we can continue as we used to in the past. -- 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 Myers, Andrew McDonald, Martje Boudien Moerman