On Thu, 25 Apr 2024 at 12:32, Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Wed, Apr 24, 2024 at 10:49 PM Zbigniew Jędrzejewski-Szmek > <zbyszek@xxxxxxxxx> wrote: > > > > On Wed, Apr 24, 2024 at 10:33:51PM -0500, Neal Gompa wrote: > > > On Wed, Apr 24, 2024 at 3:26 PM Zbigniew Jędrzejewski-Szmek > > > <zbyszek@xxxxxxxxx> wrote: > > > > > > > > On Wed, Apr 24, 2024 at 04:57:40PM +0100, Aoife Moloney wrote: > > > > > Wiki - https://fedoraproject.org/wiki/Changes/FedoraMiracle > > > > > > > > > {{package|miracle-wm}} is available in Fedora Linux 40, so it can be > > > > > installed on top of something like the existing Sway spin and > > > > > configured to reuse much of the tools used there. > > > > > > > > > > For Fedora Linux 41, once the spin is produced, people can download > > > > > and try the experience intended to be released. > > > > > > > > I applaud people trying out new window managers and doing stuff with > > > > Fedora. But the overhead of creating and distributing a spin is quite > > > > high… It seems that the contents of this spin would overlap very > > > > strongly with Sway Spin. Would it make sense to combine them and > > > > allow users to easily select one or the other? Even during boot, there > > > > could be two boot menu entries and we could provide simple instructions > > > > to switch between the desktops on an installed system. > > > > > > > > > > Aside from actually being unintuitive and confusing to people to smush > > > two spins together like that, the experience will eventually differ > > > because different tools will be used. > > > > What tools? > > > > Well, since it's based on Mir instead of wlroots, some Mir specific > tooling may be developed. One of the goals is to have Fedora Miracle > as a reference platform for showcasing and developing a community and > ecosystem around the Mir compositor library. > > Two things being discussed upstream are how to support server-side > decorations and how to support portals. Both of these are going to be > Mir specific and at least the portal stuff will likely conflict with > another spin's configuration. > > Miracle has only very slight compatibility with the Sway/i3 IPC, just > barely enough for waybar to function. Most of the Sway tooling isn't > going to work on Miracle because they rely on that IPC. > > > > Also, you overestimate the burden of creating a spin. Aside from > > > comps, kickstart definitions, and pungi config being done initially > > > (which isn't too high to begin with either), the effort required to > > > maintain a spin image is extremely low. > > > > There's also the effort of distribuiting and archiving a few > > additional gigabytes, putting up the links on the website and browsing > > through them, some additional time and and additional step that can > > fail during builds… > > > > > A large chunk of our spins are essentially semi-automatic these days, > > > and people don't really notice because at the end of the day, it's a > > > bundle of things configured together. > > > > Yes. And my point is that we can come up with a hundred or a thousands > > of such bundle definitions, and my question is whether we should > > create a separate deliverable for each possible definition. > > > > If a SIG is willing to do it and support it, I don't see why not. There's also QE efforts required to test it, and how many users will it even get, is it worth it if there's a dozen users? -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
