On Thu, Apr 24, 2025 at 6:11 PM Michel Lind <sali...@fedoraproject.org> wrote: > > On Thu, 2025-04-24 at 17:53 +0000, Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Apr 22, 2025 at 07:55:53PM +0100, Aoife Moloney via devel- > > announce wrote: > > > == Benefit to Fedora == > > > This aligns us with the effort going on upstream to retire the > > > GNOME > > > X11 session. It also aligns us with Fedora KDE. Like the Fedora KDE > > > SIG, the Fedora Workstation WG recommends and supports the Wayland > > > platform for graphics. > > > > > > Fedora Workstation has a long history of developing and promoting > > > the > > > Wayland experience for GNOME, and > > > [https://fedoraproject.org/wiki/Changes/WaylandByDefaultOnNVIDIA it > > > has been the primary experience for all users (including those with > > > NVIDIA cards) since Fedora Linux 36]. This continuation of > > > [[WaylandOnlyGNOMEWorkstationMedia|the work in Fedora Linux 41 to > > > drop > > > the X11 session from the media]] reaffirms our commitment to the > > > Wayland GNOME experience in furtherance of the goal to provide the > > > highest quality GNOME experience through Fedora Workstation. > > > > I find this motivation a bit of a stretch. > > > > Firstly, it doesn't really align us with upstream, since we're doing > > something that upstream is not doing (yet). > > > > Secondly, I see little benefit in "aligning" the Workstation Edition > > with KDE. We have both because they are different. > > > > Thirdly, I'm very happy that the WG recommends Wayland and that > > there's a long history of championing Wayland by Fedora. But this > > doesn't mean that we should drop support for an alternative. > > > > The benefits of dropping code are different for upstreams and for > > downstreams. For the upstream, dropping an feature like this can > > result in removing a lot of code, and then possibly they can get rid > > of some abstraction layers or limitations, also compile times > > improve, > > testing is simplified, etc. But for downstreams that aren't > > developing > > the code, those benefits are much smaller. The compile times improve > > a > > bit, possibly there are less subpackages, but that is just some CPU > > time. The only big change is that the support matrix is smaller. > > > > In the case of the X11 sessions, one has to explicitly select > > the session. This is something that users who explicitly want it > > will do. And if they do this, this is most likely because $something > > doesn't work well under Wayland for them. Maybe it's the fault > > of their custom config or hardware, that doesn't really matter. > > But since this is clearly opt-in, whether the feature is there or > > not does not make that much of a difference for maintainers. > > > > I don't personally care for the X11 and I haven't used it in years. > > But I think that those X11 subpackages and the users who use them are > > not a problem and there is little benefit in accelerating the removal > > of X11 before upstream. > > > Marking these as deprecated() could be a reasonable compromise - after > all, upstream is already disabling it by default for 49 and will be > removing it in 50, right? > > So marking these as deprecated seems reasonable - these will have to > eventually go away anyway, and this signals to users to not rely on > these packages for much longer and for packagers that they should not > package something that hard-depends on these. >
They were marked as deprecated since Fedora Linux 40 already. > > We had a similar discussion re openssl engines. If upstream drops > > support for a feature, we'll follow, but there is little benefit to > > us > > or our users by doing it before upstream. > > > Right. I raised this at the Workstation WG meeting when we reverted the > X11 droppage for F42 and urged that it be a proper change proposal for > F43. > In this case, there is a benefit since there are problems with it and there's no one to do anything about it. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
