Hi all,
Another week, another update mail from me.
As previously discussed [1][2], we are looking into building an openSUSE ALP Product similar in scope to openSUSE Leap.
As in, mutable base OS, multiple desktops, traditional RPM packaging, etc
For this idea to be remotely viable, we need individuals or teams willing to look into/be responsible for packaging and/or integrating at least the following:
- The Desktops (GNOME, KDE, xfce, etc) - The graphical stack (Wayland/Xorg)
As these are not expected to be provided by the SUSE ALP Server Products codebase we're going to have available as our base.
In addition, we will also need volunteers in the areas of
- Maintenance - QA
And of course, as Leap is a very broad distribution, we are also interested in anyone volunteering in any other area
However, despite both of my previous mails [1][2] calling for people to speak up and volunteer, at time of writing we effectively have _no one_ who's volunteered in any of the above areas.
We have Dominique's Team at SUSE (including Lubos, Max, Doug and my future replacement) willing to do the release management for whatever the community builds, but we need volunteers to build it.
We have Simon Lees and his much more narrowly defined 'Grassy Knoll' idea, which would likely offer only a single lightweight desktop and less packages/packages primarily maintained in Tumbleweed, possibly with very different maintenance model than Leap users are familiar with.
I understand that it can be scary to volunteer, and there are plenty of things we don't know for sure yet
- What release cadence will this openSUSE ALP Leap-alike have? - How will we do maintenance updates for the non-SUSE maintained packages? (Conservative like Leap/SLE without version bumps, or more liberal like Tumbleweed?) - How will we test/double-check the packages from SUSE ALP? How will we ensure only good updates of both SUSE and openSUSE built packages are released? - And I'm sure many more questions that I haven't even thought about yet.
The lack of clear answers to such questions cannot be an excuse for not volunteering. We can't even start having the conversations to begin figuring out the answers without having people to talk to.
So please, speak up and volunteer, ideally by openSUSE Conference (June 02) Bonus points if you happen to be going also, but that's not required.
If this silence continues as it has for the past weeks, then I imagine the only viable Plan B's are investigating more narrowly-defined offerings like Simon's and/or encouraging everyone who's going to miss Leap once it reaches its ends of life a few years from now to move towards Tumbleweed or MicroOS Desktop.
Hence the openSUSE Conference being a natural 'deadline' for this call for volunteers - if we need to come up with a Plan B, having a bunch of us all together might be a good catalyst.
Have a lot of fun,
Richard
[1] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/G... [2] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/C...
Hi,
I'm volunteering. The only thing is I have no experience building a distro, so it will be a big learning experience for sure. I tend to prefer using Tumbleweed on the desktop, but I think Leap occupies an important option for users (and servers). It deserves at least a conversation and Leap users deserve a formidable successor.
David Dyess
Hi,
The current efforts are less than 0.1 persons (FTE) to coordinate openSUSE maintenance. We get a limited amount of submits on the OBS side, almost everything comes from the SLE side.
Note that we have setup only maintenance for openSUSE Leap, but not Leap Micro as Leap Micro is pretty much only a SLE export.
We can keep it at that level at least for ALP.
So from the security side (and so largely the maintenance side), we can can likely cover a similar set of products we current supply
2 products are okay, 3 might be okay, but more will get more an more confusing and more work.
And we should be able to reuse as much work as possible between those.
From my point the Leap project should really focus on a limited set of products that our users prefer.
Ciao, Marcus
On Tue, May 02, 2023 at 09:05:37PM +0200, Richard Brown wrote:
Hi all,
Another week, another update mail from me.
As previously discussed [1][2], we are looking into building an openSUSE ALP Product similar in scope to openSUSE Leap.
As in, mutable base OS, multiple desktops, traditional RPM packaging, etc
For this idea to be remotely viable, we need individuals or teams willing to look into/be responsible for packaging and/or integrating at least the following:
- The Desktops (GNOME, KDE, xfce, etc)
- The graphical stack (Wayland/Xorg)
As these are not expected to be provided by the SUSE ALP Server Products codebase we're going to have available as our base.
In addition, we will also need volunteers in the areas of
- Maintenance
- QA
And of course, as Leap is a very broad distribution, we are also interested in anyone volunteering in any other area
However, despite both of my previous mails [1][2] calling for people to speak up and volunteer, at time of writing we effectively have _no one_ who's volunteered in any of the above areas.
We have Dominique's Team at SUSE (including Lubos, Max, Doug and my future replacement) willing to do the release management for whatever the community builds, but we need volunteers to build it.
We have Simon Lees and his much more narrowly defined 'Grassy Knoll' idea, which would likely offer only a single lightweight desktop and less packages/packages primarily maintained in Tumbleweed, possibly with very different maintenance model than Leap users are familiar with.
I understand that it can be scary to volunteer, and there are plenty of things we don't know for sure yet
- What release cadence will this openSUSE ALP Leap-alike have?
- How will we do maintenance updates for the non-SUSE maintained packages?
(Conservative like Leap/SLE without version bumps, or more liberal like Tumbleweed?)
- How will we test/double-check the packages from SUSE ALP? How will we
ensure only good updates of both SUSE and openSUSE built packages are released?
- And I'm sure many more questions that I haven't even thought about yet.
The lack of clear answers to such questions cannot be an excuse for not volunteering. We can't even start having the conversations to begin figuring out the answers without having people to talk to.
So please, speak up and volunteer, ideally by openSUSE Conference (June 02) Bonus points if you happen to be going also, but that's not required.
If this silence continues as it has for the past weeks, then I imagine the only viable Plan B's are investigating more narrowly-defined offerings like Simon's and/or encouraging everyone who's going to miss Leap once it reaches its ends of life a few years from now to move towards Tumbleweed or MicroOS Desktop.
Hence the openSUSE Conference being a natural 'deadline' for this call for volunteers - if we need to come up with a Plan B, having a bunch of us all together might be a good catalyst.
Have a lot of fun,
Richard
[1] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/G... [2] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/C...
-- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi All
Having hard a few years of complications I am now in a place where I can offer time and help.
I will need help/mentoring if someone can spare some time to answer questions/point me in the right direction as I haven't done anything on this scale but I am always happy to learn.
Cheers
Sent from Proton Mail mobile
-------- Original Message -------- On 2 May 2023, 20:05, Richard Brown < rbrown@suse.de> wrote:
Hi all, Another week, another update mail from me. As previously discussed [1][2], we are looking into building an openSUSE ALP Product similar in scope to openSUSE Leap. As in, mutable base OS, multiple desktops, traditional RPM packaging, etc For this idea to be remotely viable, we need individuals or teams willing to look into/be responsible for packaging and/or integrating at least the following: - The Desktops (GNOME, KDE, xfce, etc) - The graphical stack (Wayland/Xorg) As these are not expected to be provided by the SUSE ALP Server Products codebase we're going to have available as our base. In addition, we will also need volunteers in the areas of - Maintenance - QA And of course, as Leap is a very broad distribution, we are also interested in anyone volunteering in any other area However, despite both of my previous mails [1][2] calling for people to speak up and volunteer, at time of writing we effectively have _no one_ who's volunteered in any of the above areas. We have Dominique's Team at SUSE (including Lubos, Max, Doug and my future replacement) willing to do the release management for whatever the community builds, but we need volunteers to build it. We have Simon Lees and his much more narrowly defined 'Grassy Knoll' idea, which would likely offer only a single lightweight desktop and less packages/packages primarily maintained in Tumbleweed, possibly with very different maintenance model than Leap users are familiar with. I understand that it can be scary to volunteer, and there are plenty of things we don't know for sure yet - What release cadence will this openSUSE ALP Leap-alike have? - How will we do maintenance updates for the non-SUSE maintained packages? (Conservative like Leap/SLE without version bumps, or more liberal like Tumbleweed?) - How will we test/double-check the packages from SUSE ALP? How will we ensure only good updates of both SUSE and openSUSE built packages are released? - And I'm sure many more questions that I haven't even thought about yet. The lack of clear answers to such questions cannot be an excuse for not volunteering. We can't even start having the conversations to begin figuring out the answers without having people to talk to. So please, speak up and volunteer, ideally by openSUSE Conference (June 02) Bonus points if you happen to be going also, but that's not required. If this silence continues as it has for the past weeks, then I imagine the only viable Plan B's are investigating more narrowly-defined offerings like Simon's and/or encouraging everyone who's going to miss Leap once it reaches its ends of life a few years from now to move towards Tumbleweed or MicroOS Desktop. Hence the openSUSE Conference being a natural 'deadline' for this call for volunteers - if we need to come up with a Plan B, having a bunch of us all together might be a good catalyst. Have a lot of fun, Richard [1] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/G... [2] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/C... -- 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
Richard,
I'm definitely interested in volunteering for this project. I'd be glad to work on creating/maintaining packages or other maintenance tasks. Let's get this going!
On 2023-05-03 11:11, Marcus Meissner wrote:
Hi,
The current efforts are less than 0.1 persons (FTE) to coordinate openSUSE maintenance. We get a limited amount of submits on the OBS side, almost everything comes from the SLE side.
Note that we have setup only maintenance for openSUSE Leap, but not Leap Micro as Leap Micro is pretty much only a SLE export.
We can keep it at that level at least for ALP.
So from the security side (and so largely the maintenance side), we can can likely cover a similar set of products we current supply
2 products are okay, 3 might be okay, but more will get more an more confusing and more work.
And we should be able to reuse as much work as possible between those.
From my point the Leap project should really focus on a limited set
of products that our users prefer.
Ciao, Marcus
Thank you Marcus, this is really very helpful, just the sort of info we need and will help us scope what we can realistically do going forward
As openSUSE ALP Micro and openSUSE ALP Bedrock are just like Leap Micro (pretty much exports), is your 2-3 products limit in ADDITION to those two export products?
Or are you basically saying "we have resources for a single new openSUSE ALP community built product"?
Regards,
Hi,
On Wed, May 03, 2023 at 12:14:19PM +0200, Richard Brown wrote:
On 2023-05-03 11:11, Marcus Meissner wrote:
Hi,
The current efforts are less than 0.1 persons (FTE) to coordinate openSUSE maintenance. We get a limited amount of submits on the OBS side, almost everything comes from the SLE side.
Note that we have setup only maintenance for openSUSE Leap, but not Leap Micro as Leap Micro is pretty much only a SLE export.
We can keep it at that level at least for ALP.
So from the security side (and so largely the maintenance side), we can can likely cover a similar set of products we current supply
2 products are okay, 3 might be okay, but more will get more an more confusing and more work.
And we should be able to reuse as much work as possible between those.
From my point the Leap project should really focus on a limited set
of products that our users prefer.
Ciao, Marcus
Thank you Marcus, this is really very helpful, just the sort of info we need and will help us scope what we can realistically do going forward
As openSUSE ALP Micro and openSUSE ALP Bedrock are just like Leap Micro (pretty much exports), is your 2-3 products limit in ADDITION to those two export products?
Or are you basically saying "we have resources for a single new openSUSE ALP community built product"?
As said in the call, I think we can do Leap/ALP Micro, Leap/ALP Bedrock + 1 Leap general purpose distro.
Ciao, Marcus
Hi,
I'm willing to help out on the openQA part. However a requirement would be to have something to test on. I guess I'll join the party later on, once there is something to be tested.
Looking forward to some discussions at the openSUSE Conference!
Best, phoenix
On Tue, 2023-05-02 at 21:05 +0200, Richard Brown wrote:
Hi all,
Another week, another update mail from me.
As previously discussed [1][2], we are looking into building an openSUSE ALP Product similar in scope to openSUSE Leap.
As in, mutable base OS, multiple desktops, traditional RPM packaging, etc
For this idea to be remotely viable, we need individuals or teams willing to look into/be responsible for packaging and/or integrating at least the following:
- The Desktops (GNOME, KDE, xfce, etc)
- The graphical stack (Wayland/Xorg)
As these are not expected to be provided by the SUSE ALP Server Products codebase we're going to have available as our base.
In addition, we will also need volunteers in the areas of
- Maintenance
- QA
And of course, as Leap is a very broad distribution, we are also interested in anyone volunteering in any other area
However, despite both of my previous mails [1][2] calling for people to speak up and volunteer, at time of writing we effectively have _no one_ who's volunteered in any of the above areas.
We have Dominique's Team at SUSE (including Lubos, Max, Doug and my future replacement) willing to do the release management for whatever the community builds, but we need volunteers to build it.
We have Simon Lees and his much more narrowly defined 'Grassy Knoll' idea, which would likely offer only a single lightweight desktop and less packages/packages primarily maintained in Tumbleweed, possibly with very different maintenance model than Leap users are familiar with.
I understand that it can be scary to volunteer, and there are plenty of things we don't know for sure yet
- What release cadence will this openSUSE ALP Leap-alike have?
- How will we do maintenance updates for the non-SUSE maintained
packages? (Conservative like Leap/SLE without version bumps, or more liberal like Tumbleweed?)
- How will we test/double-check the packages from SUSE ALP? How will
we ensure only good updates of both SUSE and openSUSE built packages are released?
- And I'm sure many more questions that I haven't even thought about
yet.
The lack of clear answers to such questions cannot be an excuse for not volunteering. We can't even start having the conversations to begin figuring out the answers without having people to talk to.
So please, speak up and volunteer, ideally by openSUSE Conference (June 02) Bonus points if you happen to be going also, but that's not required.
If this silence continues as it has for the past weeks, then I imagine the only viable Plan B's are investigating more narrowly-defined offerings like Simon's and/or encouraging everyone who's going to miss Leap once it reaches its ends of life a few years from now to move towards Tumbleweed or MicroOS Desktop.
Hence the openSUSE Conference being a natural 'deadline' for this call for volunteers - if we need to come up with a Plan B, having a bunch of us all together might be a good catalyst.
Have a lot of fun,
Richard
[1] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/G... [2] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/C...
On 2023-05-03 15:37, Felix Niederwanger wrote:
Hi,
I'm willing to help out on the openQA part. However a requirement would be to have something to test on. I guess I'll join the party later on, once there is something to be tested.
Looking forward to some discussions at the openSUSE Conference!
Best, phoenix
Hi Felix,
I strongly disagree that you should need to wait to join the party :)
As should be readily apparent based on my mails to date, the exact scope of what we're going to be able to offer is a variable.
The headline goal might be to offer something based on ALP that acts like Leap, but how feasible that is really depends on who volunteers and what those volunteers are able and willing to build.
Given the scope of what we offer could vary wildly, I think it's important someone from the openQA part is involved at the earliest opportunities - at the very least so you have a good understanding of WTF is going on, or ideally, so you can help influence any decisions and make sure folk don't end up trying to build something "untestable"
So, thanks for volunteering, you can expect to hear more from me as things shape up ;)
Hi,
I can help as I use and love Leap (Gnome). My time is limited, but I can do my best to help with Gnome.
Best,
Alexandre Vicenzi
Hello,
------- Original Message ------- On Wednesday, May 3rd, 2023 at 3:05 AM, Richard Brown rbrown@suse.de wrote:
As previously discussed [1][2], we are looking into building an openSUSE ALP Product similar in scope to openSUSE Leap.
As in, mutable base OS, multiple desktops, traditional RPM packaging, etc
For this idea to be remotely viable, we need individuals or teams willing to look into/be responsible for packaging and/or integrating at least the following:
- The Desktops (GNOME, KDE, xfce, etc)
You can of count on me to continue contribute and work on Xfce the best I can and ensure it's well supported.
Best, Maurizio
If you would see any space for help from volunteers, then we've started to collect areas where the project (not necessarily just Leap 16) could use some help. We Just need to make sure that there is a space for help in a given area. Sometimes it could be quite tricky. https://etherpad.opensuse.org/p/help
Any thoughts would be welcome.
The end goal is to turn these ideas/areas into banners at openSUSE Conference etc.
Otherwise, I'm not as super concerned about volunteers, given my experience from Leap 15.X.
Resources were always a struggle and we always made it. I see it more as an opportunity for areas, where we've been previously "held back more" by SUSE.
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.
I also understand that Richard wants to see a change compared to how we did things in past. Perhaps also see increased ownership, and accountability, and ensure project success before kicking the ball. I have nothing against it, and appreciate the raised awareness. I am personally interested in how that turns out. Just to remind everyone that we have some bad experience with commitment ahead of time (see e.g. armv7 on Leap).
Cheers
Lubos
On Wed, 2023-05-03 at 13:48 +0200, Marcus Meissner wrote:
Hi,
On Wed, May 03, 2023 at 12:14:19PM +0200, Richard Brown wrote:
On 2023-05-03 11:11, Marcus Meissner wrote:
Hi,
The current efforts are less than 0.1 persons (FTE) to coordinate openSUSE maintenance. We get a limited amount of submits on the OBS side, almost everything comes from the SLE side.
Note that we have setup only maintenance for openSUSE Leap, but not Leap Micro as Leap Micro is pretty much only a SLE export.
We can keep it at that level at least for ALP.
So from the security side (and so largely the maintenance side), we can can likely cover a similar set of products we current supply
2 products are okay, 3 might be okay, but more will get more an more confusing and more work.
And we should be able to reuse as much work as possible between those.
From my point the Leap project should really focus on a limited set
of products that our users prefer.
Ciao, Marcus
Thank you Marcus, this is really very helpful, just the sort of info we need and will help us scope what we can realistically do going forward
As openSUSE ALP Micro and openSUSE ALP Bedrock are just like Leap Micro (pretty much exports), is your 2-3 products limit in ADDITION to those two export products?
Or are you basically saying "we have resources for a single new openSUSE ALP community built product"?
As said in the call, I think we can do Leap/ALP Micro, Leap/ALP Bedrock + 1 Leap general purpose distro.
Ciao, Marcus
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.
This tiny team might be enough, but I think it's also reasonable to ask whether or not we instead attempt something a little less ambitious and a little more focused given the scale of interest people are demonstrating towards this effort.
My view is I'd rather we try something small, and scale it up based on contributions, rather than try something huge (and a Leap-a-like is huge), burn out a dozen contributors in the process and be able to produce less as Project for quite a long while as a result.
In the next few days I'll be reaching out to the fewer-than-a-dozen who've volunteered and try and find a way to get us to all talk together about figuring out what the best next steps are.
Regards,
Hello,
On Tue, 2023-05-02 at 21:05 +0200, Richard Brown wrote:
Hi all,
Another week, another update mail from me.
As previously discussed [1][2], we are looking into building an openSUSE ALP Product similar in scope to openSUSE Leap.
As in, mutable base OS, multiple desktops, traditional RPM packaging, etc
For this idea to be remotely viable, we need individuals or teams willing to look into/be responsible for packaging and/or integrating at least the following:
- The Desktops (GNOME, KDE, xfce, etc)
- The graphical stack (Wayland/Xorg)
As these are not expected to be provided by the SUSE ALP Server Products codebase we're going to have available as our base.
In addition, we will also need volunteers in the areas of
- Maintenance
- QA
And of course, as Leap is a very broad distribution, we are also interested in anyone volunteering in any other area
However, despite both of my previous mails [1][2] calling for people to speak up and volunteer, at time of writing we effectively have _no one_ who's volunteered in any of the above areas.
We have Dominique's Team at SUSE (including Lubos, Max, Doug and my future replacement) willing to do the release management for whatever the community builds, but we need volunteers to build it.
We have Simon Lees and his much more narrowly defined 'Grassy Knoll' idea, which would likely offer only a single lightweight desktop and less packages/packages primarily maintained in Tumbleweed, possibly with very different maintenance model than Leap users are familiar with.
I understand that it can be scary to volunteer, and there are plenty of things we don't know for sure yet
- What release cadence will this openSUSE ALP Leap-alike have?
- How will we do maintenance updates for the non-SUSE maintained
packages? (Conservative like Leap/SLE without version bumps, or more liberal like Tumbleweed?)
- How will we test/double-check the packages from SUSE ALP? How will
we ensure only good updates of both SUSE and openSUSE built packages are released?
- And I'm sure many more questions that I haven't even thought about
yet.
The lack of clear answers to such questions cannot be an excuse for not volunteering. We can't even start having the conversations to begin figuring out the answers without having people to talk to.
So please, speak up and volunteer, ideally by openSUSE Conference (June 02) Bonus points if you happen to be going also, but that's not required.
If this silence continues as it has for the past weeks, then I imagine the only viable Plan B's are investigating more narrowly-defined offerings like Simon's and/or encouraging everyone who's going to miss Leap once it reaches its ends of life a few years from now to move towards Tumbleweed or MicroOS Desktop.
Hence the openSUSE Conference being a natural 'deadline' for this call for volunteers - if we need to come up with a Plan B, having a bunch of us all together might be a good catalyst.
Have a lot of fun,
Richard
[1] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/G... [2] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/C...
I offer myself as a volunteer.
I have very little experience since I started contributing only recently by updating two packages. If I can help somehow, I'll be pleased to do that.
Regards, Emiliano
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.
This tiny team might be enough, but I think it's also reasonable to ask whether or not we instead attempt something a little less ambitious and a little more focused given the scale of interest people are demonstrating towards this effort.
My view is I'd rather we try something small, and scale it up based on contributions, rather than try something huge (and a Leap-a-like is huge), burn out a dozen contributors in the process and be able to produce less as Project for quite a long while as a result.
This is probably a sensible starting point, if we start out with something smallish the community can then add what they'd like on top and then in a few months we will actually start to have a good measure of what the community involvement will look like. I suspect once we get to a point where people start to see they have everything they need except for package X and Y they'll probably start to contribute them.
As a suggested starting point https://build.opensuse.org/project/show/home:simotek:GrassyKnoll:Backports has 392 package and hasn't been touched in 3 months, of those packages 4 are failing 8 are unresolvable and 6 are broken. But the IBS version of SUSE:ALP might also have other packages that have changed so trying to get these packages building against the SUSE:ALP from IBS would probably be a good start.
In the next few days I'll be reaching out to the fewer-than-a-dozen who've volunteered and try and find a way to get us to all talk together about figuring out what the best next steps are.
I'll be traveling from the end of the week but hopefully that means that some of us can chat in person soon.
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.
Hi,
On 08/05/2023 10.58, 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 […]
I guess that's correct. Speaking for myself – or rather the complete SUSE QE Tools team – we commit to maintain https://openqa.opensuse.org and the software and infrastructure behind it. If in the rare chance that openSUSE ALP will require any significant changes in our domain we will help but I doubt that any relevant changes are even necessary on that level. What we will not be able to contribute is adapt or create the product itself or according test code which is the challenge that Richard rightly puts the focus on.
Have fun, Oliver
Hello.
I'd like to volunteer to help with packaging for this. I'm very interesting in helping out with packaging GNOME, but I'm also happy to help with any other packages needed really.
Antonio Teixeira
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.
On 08/05/2023 10.58, Richard Brown wrote:
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.
I'm certainly interested as well, as I use current Leap a lot and Factory still has strange issues that I'd need to track down.
Hi all,
I was really pleased to be part of the Simon's hack-week project. So naturally, I would be glad to be volunteer !
Have a good week, Valentin
On Tue, 2023-05-02 at 21:05 +0200, Richard Brown wrote:
Hi all,
Another week, another update mail from me.
As previously discussed [1][2], we are looking into building an openSUSE ALP Product similar in scope to openSUSE Leap.
As in, mutable base OS, multiple desktops, traditional RPM packaging, etc
For this idea to be remotely viable, we need individuals or teams willing to look into/be responsible for packaging and/or integrating at least the following:
- The Desktops (GNOME, KDE, xfce, etc)
- The graphical stack (Wayland/Xorg)
As these are not expected to be provided by the SUSE ALP Server Products codebase we're going to have available as our base.
In addition, we will also need volunteers in the areas of
- Maintenance
- QA
And of course, as Leap is a very broad distribution, we are also interested in anyone volunteering in any other area
However, despite both of my previous mails [1][2] calling for people to speak up and volunteer, at time of writing we effectively have _no one_ who's volunteered in any of the above areas.
We have Dominique's Team at SUSE (including Lubos, Max, Doug and my future replacement) willing to do the release management for whatever the community builds, but we need volunteers to build it.
We have Simon Lees and his much more narrowly defined 'Grassy Knoll' idea, which would likely offer only a single lightweight desktop and less packages/packages primarily maintained in Tumbleweed, possibly with very different maintenance model than Leap users are familiar with.
I understand that it can be scary to volunteer, and there are plenty of things we don't know for sure yet
- What release cadence will this openSUSE ALP Leap-alike have?
- How will we do maintenance updates for the non-SUSE maintained
packages? (Conservative like Leap/SLE without version bumps, or more liberal like Tumbleweed?)
- How will we test/double-check the packages from SUSE ALP? How will
we ensure only good updates of both SUSE and openSUSE built packages are released?
- And I'm sure many more questions that I haven't even thought about
yet.
The lack of clear answers to such questions cannot be an excuse for not volunteering. We can't even start having the conversations to begin figuring out the answers without having people to talk to.
So please, speak up and volunteer, ideally by openSUSE Conference (June 02) Bonus points if you happen to be going also, but that's not required.
If this silence continues as it has for the past weeks, then I imagine the only viable Plan B's are investigating more narrowly-defined offerings like Simon's and/or encouraging everyone who's going to miss Leap once it reaches its ends of life a few years from now to move towards Tumbleweed or MicroOS Desktop.
Hence the openSUSE Conference being a natural 'deadline' for this call for volunteers - if we need to come up with a Plan B, having a bunch of us all together might be a good catalyst.
Have a lot of fun,
Richard
[1] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/G... [2] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/C...
-
Alexandre Vicenzi -
Antonio Teixeira -
Bernhard M. Wiedemann -
David Dyess -
Emiliano Langella -
Felix Niederwanger -
Kris Scott -
Lubos Kocman -
Marcus Meissner -
Maurizio Galli -
Oliver Kurz -
Richard Brown -
Robin Shepheard -
Simon Lees -
Valentin Lefebvre