On 4/24/23 22:10, Neal Gompa wrote:

On Mon, Apr 24, 2023 at 8:33 AM Richard Brown rbrown@suse.de wrote:

...

Hi all,

It has been almost one week since we started the thread sharing SUSE's plans for ALP and opening the door for discussions about what openSUSE will build based on it [1]

Given the thread got (understandably) long, I wanted to take this opportunity to summarise where we stand today:

• There seemed to be general consensus to SUSE's plan to offer openSUSE

branded 1:1 equivalents of their ALP "Server" Products (currently known as Bedrock and Micro)

• APlanas suggested openSUSE should not build anything based on SUSE

ALP, but instead focus on adapting Factory (and MicroOS/MicroOS Desktop) to be more ALP like [2]

• I replied that I believe Alberto's suggestions to be inevitable but

something to be done AFTER we're sure the community is building from ALP everything it wishes to [3]

• Simon Lees suggested an openSUSE ALP Product that would be

Tumbleweed/Leap like but focused on one of the lighter desktops like XFCE. This seemed to be mostly to mitigate the developer/maintenance requirements in the absence of being able to draw from SUSE-developed Desktop packages as in the past [4]

• Lubos suggested an openSUSE ALP Product that would be like "old Leap",

but forking from Tumbleweed anything that cannot be provided by SUSE:ALP. The biggest fears/threats to this idea include a possible lack of interested contributors, and a lack of resources for maintenance and QA [5]

There has not been many/any voices speaking up in support for either Simons or Lubos' suggestions.

Lubos' suggestion in particular really will require broad support from lots of groups within the community, including

• Maintenance
• QA
• All the teams behind the Desktop stacks wanting to be included (KDE,

GNOME, et al)

• And possibly most devel project maintainers, depending on details like

the cadence of forking from Tumbleweed, they could find themselves needing to maintain versions in this openSUSE ALP "old Leap" for some years (I'd estimate upto 5), and not be able to benefit from SUSE's work in this area as they did with SLE+Leap because ALP will likely often most such things containerised.

Therefore it would be really nice if people from the above groups, either individually or with one person speaking for the whole teams, could speak up and let us all know how they feel about this proposal, so we can get a better feeling about how viable it may be.

Given the state of X11, I do not think it is a good idea for any X11 experience to be part of ALP and we should be looking to drive desktop environments/projects on ALP to use Wayland from beginning to end. I am willing to help out there as much as I can.

While I agree wayland will be superior when it is all there and stable, outside the major desktops we are still along way from that point (Enlightenment is still working on multi monitor support etc), alongside that tools I use daily such as barrier (synergy replacement) have no way to function with wayland yet which leaves me at a point of supporting X11 in ALP (especially while its still in tumbleweed) being significantly less effort then getting all my required usecases working with wayland.

Hopefully in 5ish years when ALP is next branched fresh from tumbleweed again that situation will have changed, But for atleast the last 10 years we've been told Wayland is about 5 years from being production ready and I still see that as probably the case today atleast for the more Niche usecases of my desktop linux setup.

On Wed, Apr 26, 2023 at 2:55 AM Jiri Slaby jslaby@suse.cz wrote:

On 26. 04. 23, 7:49, Simon Lees wrote:

...

On 4/24/23 22:10, Neal Gompa wrote:

...

On Mon, Apr 24, 2023 at 8:33 AM Richard Brown rbrown@suse.de wrote:

...

Hi all,

It has been almost one week since we started the thread sharing SUSE's plans for ALP and opening the door for discussions about what openSUSE will build based on it [1]

Given the thread got (understandably) long, I wanted to take this opportunity to summarise where we stand today:

• There seemed to be general consensus to SUSE's plan to offer openSUSE

branded 1:1 equivalents of their ALP "Server" Products (currently known as Bedrock and Micro)

• APlanas suggested openSUSE should not build anything based on SUSE

ALP, but instead focus on adapting Factory (and MicroOS/MicroOS Desktop) to be more ALP like [2]

• I replied that I believe Alberto's suggestions to be inevitable but

something to be done AFTER we're sure the community is building from ALP everything it wishes to [3]

• Simon Lees suggested an openSUSE ALP Product that would be

Tumbleweed/Leap like but focused on one of the lighter desktops like XFCE. This seemed to be mostly to mitigate the developer/maintenance requirements in the absence of being able to draw from SUSE-developed Desktop packages as in the past [4]

• Lubos suggested an openSUSE ALP Product that would be like "old Leap",

but forking from Tumbleweed anything that cannot be provided by SUSE:ALP. The biggest fears/threats to this idea include a possible lack of interested contributors, and a lack of resources for maintenance and QA [5]

There has not been many/any voices speaking up in support for either Simons or Lubos' suggestions.

Lubos' suggestion in particular really will require broad support from lots of groups within the community, including

• Maintenance
• QA
• All the teams behind the Desktop stacks wanting to be included (KDE,

GNOME, et al)

• And possibly most devel project maintainers, depending on details like

the cadence of forking from Tumbleweed, they could find themselves needing to maintain versions in this openSUSE ALP "old Leap" for some years (I'd estimate upto 5), and not be able to benefit from SUSE's work in this area as they did with SLE+Leap because ALP will likely often most such things containerised.

Therefore it would be really nice if people from the above groups, either individually or with one person speaking for the whole teams, could speak up and let us all know how they feel about this proposal, so we can get a better feeling about how viable it may be.

Given the state of X11, I do not think it is a good idea for any X11 experience to be part of ALP and we should be looking to drive desktop environments/projects on ALP to use Wayland from beginning to end. I am willing to help out there as much as I can.

While I agree wayland will be superior when it is all there and stable, outside the major desktops we are still along way from that point (Enlightenment is still working on multi monitor support etc), alongside that tools I use daily such as barrier (synergy replacement) have no way to function with wayland yet which leaves me at a point of supporting X11 in ALP (especially while its still in tumbleweed) being significantly less effort then getting all my required usecases working with wayland.

I am using exclusively wayland on TW. The only apps in my xlsclients output were vim, thunderbird, librecad, sddm.

MOZ_ENABLE_WAYLAND=1 changes TB. But TB crashes from time to time because of "loss of wayland window". So they know well why the default is still Xwayland. There is a long standing bug for "wayland support".

LibreCAD behaves incorrectly under wayland. QT_QPA_PLATFORM=xcb solves this of course. Dunno upstream status.

I have ~20 wayland-for-vim patches on the top of factory. They are still not merged upstream.

I use sddm-git to have some sort of wayland support. It's incomplete and buggy, so before 0.20 real release, not much cookies.

It's pretty much working now with the latest git code, the remaining issues are dependent on which compositor you use for the SDDM wayland greeter.

Another stupidity is inability to forward graphical apps over ssh/tcp under wayland. Or I haven't found a way. But it's a design flaw of wayland IIUC.

I've used waypipe(1) with great success: https://www.mankier.com/1/waypipe

So I would NOT recommend anyone to use wayland without Xwayland (and complete X stack behind that) in production these days. Wayland's still way too buggy/incomplete, causes random crashes, or unusable behavior. Neither the main desktops are wayland completely ready. One of bad examples is sddm. But all is slowly changing. So your 5 years sounds sensible.

Nobody should be suggesting the removal of Xwayland. But Xwayland does not imply the complete X stack. Xwayland doesn't rely on any of the larger X session infrastructure, especially the X server driver stack.

Xwayland is also a separate package from the "regular" X11 session stack, including the "full" X server.

-- 真実はいつも一つ！/ Always, there's only one truth!

On 2023-04-25 22:23, Robert Schweikert via openSUSE Factory wrote:

Hi,

On 4/24/23 08:33, Richard Brown wrote:

...

Lubos' suggestion in particular really will require broad support from lots of groups within the community, including

• Maintenance
• QA
• All the teams behind the Desktop stacks wanting to be included (KDE,

GNOME, et al)

• And possibly most devel project maintainers, depending on details

like the cadence of forking from Tumbleweed, they could find themselves needing to maintain versions in this openSUSE ALP "old Leap" for some years (I'd estimate upto 5), and not be able to benefit from SUSE's work in this area as they did with SLE+Leap because ALP will likely often most such things containerised.

Therefore it would be really nice if people from the above groups, either individually or with one person speaking for the whole teams, could speak up and let us all know how they feel about this proposal, so we can get a better feeling about how viable it may be.

Well ultimately I think we just have to see what itches people want to scratch when the time comes. Unlike in the corporate setting where things are driven by customer asks, and as was pointed out in this thread, that's not how it works in the community.

Said a different way, developers will join projects that build ontop of/from ALP or projects that avoid ALP if they have an itch to scratch. Then we'll see which projects build momentum from a dev perspective and we'll see which projects gather users.

I do not disagree, but your views highlight an inherent tension between grand-plans like the one shared by Lubos and the reality of the "itches people scratch" model.

There's a lot of work that needs to be done to create an environment where people can just dive in and scratch their itches.

With Lubos and Dominiques team we have a good chunk of that - we can trust they are going to Release Manage whatever the community decides to build.

But who's going to handle maintenance updates? We're going to have a lot more packages that aren't co-maintained by SUSE with this grand-plan, so who's gonna do that work? Will we have enough people to do manage the maintenance process like Leap/old openSUSE, or do we need to think of a newer process that fits with the people we do have to do it?

What about QA? Lubos' grand-plan calls for a product as broad as Leap, so I assume we need testing as broad as we have for Leap. But we won't have an overlap with what SUSE are doing for ALP QA. So who's going to do that work? Or do we change what/how we do QA to fits with the people we have to do it?

Hence my general call for feedback here.. I'm pointing out that Lubos' suggestion, while clearly appealing for our userbase, has some pretty obvious itches that will need to be scratched to make the concept viable.

I'm trying to get a feeling as to whether we have those scratchers at the ready, waiting in the wings, or at least somewhat interested in the concept.

Else we need to adjust the plan into something viable for what we've got, so we can keep offering platforms for any ol contributor to roll up and scratch whatever itches they like.

I think it would be bad to just accept Lubos' idea as golden and go charging forward, setting everyone's expectations higher than we have any reasonable chance of achieving. Speaking from experience, it can be a bloody mess disentangling a project once it's led into such a hole :)

So please, folk, especially Maintenance, QA, Desktop packagers and devel project contributors (especially of core componants), please speak up. We need to know what you think of this :)

Hi,

On 4/26/23 05:15, Richard Brown wrote:

On 2023-04-25 22:23, Robert Schweikert via openSUSE Factory wrote:

...

Hi,

On 4/24/23 08:33, Richard Brown wrote:

...

...

Lubos' suggestion in particular really will require broad support from lots of groups within the community, including

• Maintenance
• QA
• All the teams behind the Desktop stacks wanting to be included

(KDE, GNOME, et al)

• And possibly most devel project maintainers, depending on details

like the cadence of forking from Tumbleweed, they could find themselves needing to maintain versions in this openSUSE ALP "old Leap" for some years (I'd estimate upto 5), and not be able to benefit from SUSE's work in this area as they did with SLE+Leap because ALP will likely often most such things containerised.

Therefore it would be really nice if people from the above groups, either individually or with one person speaking for the whole teams, could speak up and let us all know how they feel about this proposal, so we can get a better feeling about how viable it may be.

Well ultimately I think we just have to see what itches people want to scratch when the time comes. Unlike in the corporate setting where things are driven by customer asks, and as was pointed out in this thread, that's not how it works in the community.

Said a different way, developers will join projects that build ontop of/from ALP or projects that avoid ALP if they have an itch to scratch. Then we'll see which projects build momentum from a dev perspective and we'll see which projects gather users.

I do not disagree, but your views highlight an inherent tension between grand-plans

Well maybe the forging of grand-plans is a problem. Ultimately those that do the work, package stuff, fix bugs etc. decide for themselves whether or not they want to be part of the grand-plan or not.

like the one shared by Lubos and the reality of the "itches people scratch" model.

There's a lot of work that needs to be done to create an environment where people can just dive in and scratch their itches.

Well, I don't know, was it a whole lot of work for Simon et al to setup the project to build GrassyKnoll? Yes there is administrative work if that goes forward, bugzilla setup, possibly move the project from Home: to some "more official" place, whatever "more official" may mean. But if I have an itch now I can submit it to GrassyKnoll now.

With Lubos and Dominiques team we have a good chunk of that - we can trust they are going to Release Manage whatever the community decides to build.

Well without having a technical steering committee, on purpose, I am not certain their will be a "collective explicit" decision, which I think you are seeking. Any decisions will probably be more implicit and then externalized by those that are willing to put in the effort.

But who's going to handle maintenance updates?

Well maybe what we consider maintenance updates stays the same for ALP as those packages continue to go through the SUSE maintenance process. For everything else this is likely to change and maybe the name changes, maybe a "maintenance update" becomes just a regular update and might include a version bump, who knows. Trying to plan such things without knowing what the landscape is going to look like is difficult at best.

We're going to have a lot more packages that aren't co-maintained by SUSE with this grand-plan, so who's gonna do that work?

I don't know, we'll find out, maybe the answer is no one. Maybe we have the "products" SUSE pushes out and a few efforts that some individuals or small groups run that meet their needs. Maybe those projects grow to meet more developers needs or maybe they'll stay small.

Will we have enough people to do manage the maintenance process like Leap/old openSUSE, or do we need to think of a newer process that fits with the people we do have to do it?

I suppose we'll have to leave that up to the individuals/teams that drive those projects. I don't see how some external person/team would have any authority to impose some kind of maintenance process on GrassyKnoll or efforts like it.

What about QA? Lubos' grand-plan calls for a product as broad as Leap, so I assume we need testing as broad as we have for Leap. But we won't have an overlap with what SUSE are doing for ALP QA.

Well than the person making the plan better be prepared to implement the plan.

Don't get me wrong, I think it is great to ask the questions, which implicitly create a "Help Wanted" request. As such maybe a different approach where we make the "Help Wanted" more explicit may help. Write down everything we need and where we will no longer get the help from SUSE developers that maintain packages that end up in Leap as a positive side effect. Put that list on the wiki and shop it around. Maybe we'll find some takers.

So who's going to do that work?

I don't know, maybe no one.

Or do we change what/how we do QA to fits with the people we have to do it?

Hence my general call for feedback here.. I'm pointing out that Lubos' suggestion, while clearly appealing for our userbase, has some pretty obvious itches that will need to be scratched to make the concept viable.

I'm trying to get a feeling as to whether we have those scratchers at the ready, waiting in the wings, or at least somewhat interested in the concept.

Else we need to adjust the plan into something viable for what we've got, so we can keep offering platforms for any ol contributor to roll up and scratch whatever itches they like.

I think it would be bad to just accept Lubos' idea as golden and go charging forward, setting everyone's expectations higher than we have any reasonable chance of achieving. Speaking from experience, it can be a bloody mess disentangling a project once it's led into such a hole :)

So please, folk, especially Maintenance, QA, Desktop packagers and devel project contributors (especially of core componants), please speak up. We need to know what you think of this :)

While the other things I stated are more general in the following I can only speak for myself. I am pretty much in the middle of ALP and there are so many concepts that are TBD and so many questions that are open that I cannot tell you what this looks like. As such before I commit any time to openSUSE I need to get a much better understanding of what my day job brings. If the current relatively small extra effort to benefit openSUSE no longer works I have to evaluate whether or not I have the energy to up the ante or not. I don't know that yet.

Later, Robert