
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. 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. 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. regards, -- js suse labs