On Thu, Apr 25, 2024 at 5:31 AM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > 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? Nonblocking spins *don't* get QA efforts aside from community users who test it and report issues. Of course the users of the spin would be encouraged to test and help with the evolution of the spin. The only variants that get QA attention as a matter of course are GNOME/Workstation, KDE, Server, Cloud, CoreOS, IoT, the base containers, and the toolbox container. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ 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
