On 5/8/23 20:56, Richard Brown wrote:
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.
I think it would be insane to try and put different desktop environments into different repo's so to keep life simple lets just presume that we are going to treat it as a single "Leap 16" for lack of a better working name product. Which means yes we will probably have to teach Agama not to install everything and if Agama has a "Pattern Selection" area that is likely the best way to do it. Unless we can "Trick" it into thinking that one product is actually multiple products. As for what actually needs to be installed for Gnome, Enlightenment and XFCE we already have a pretty good idea there based off the kiwi files we created for the live iso's. I agree that the yast route is probably not the best one given long term it'd leave us with something we'd have to maintain ourselves so i'm just going to trim that part. But one thing we obviously found with that is it might lead us to no longer offering installation from a running livecd until someone makes the required adaptations. So yes there are still unanswered questions that will require more time but I guess you'd say i'm somewhat more optimistic then you based on the work i've already done. -- 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