You know that Cinnamon is an X11-only desktop, right? X11-based desktops are not in great shape because the X server itself isn't in good shape.

Yes, I understand that cinnamon has not transitioned to wayland.
But I've been using Cinnamon + X11 on my m1 macbook air and the performance has been stellar.
I don't really see a distinction between offering this as an install option for fedora-asahi vs having a dnf group install Cinnamon Desktop option....or a Fedora Cinnamon Spin install option.
This is simply about providing the choice to end-users.
However, in event that we receive reports of any indication of instability, then yes it would prudent to rescind support for Cinnamon as an install option.
But I believe we should allow the actual facts to guide us here.
Let's see what problems (if any) users actually run into -- and then adjust course accordingly.

Damn, you know what....until this PR gets merged (and the xorg-x11-server rpm patched) https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1021

We need to add this X11 config to our build somehow.
https://github.com/AsahiLinux/PKGBUILDs/blob/main/asahi-configs/30-modeset.conf config,

Any thoughts on how to best approach that?

Well, let's hold off until we get the X server stuff squared away first.

The x server stuff was squared away last month:
https://bugzilla.redhat.com/show_bug.cgi?id=2152414

I've merged this now, though I don't plan on supporting X11-based environments fully due to limitations and baggage around the X server. That aligns with upstream Fedora (where the only release-blocking desktops are GNOME and KDE Plasma, and both use Wayland now).

I don't plan on supporting X11-based environments fully...

I thought that's what this was leading up to. I respectfully disagree on this point though. I feel users should be able to make their own choice as to what desktop they wish to use (on that same token -- they should be made aware of the limitations of X11, and thus making an educated choice).

And I'm not sure what a "release-blocking desktop" is -- but that language makes it sound like its an exclusive club reserved for first-class citizens.
To be fair, I think the Minimal (kiwi) profile would suffice for alternate desktop installs.
If cinnamon isn't going to to be fully supported, then it would be better to just delete that profile altogether.

With that said, I think there is room for an additional "release-blocking desktop".
Something that's more traditional then GNOME, but more minimalistic then KDE (sorry, just way too many options). Budgie might be a good fit for that. I'll test drive that once the F38 beta is released.

There are a set of desktops that are actively tested by OpenQA, validated by Fedora QA, and if they don't work, they stop the development process until they're fixed. Right now, that's GNOME and KDE Plasma. The SIGs for the other desktops have not stepped up to the point that they could be added to this list.

The list of release-blocking deliverables is here: https://docs.fedoraproject.org/en-US/releases/f38/blocking/

And the OpenQA tests can be seen here: https://pagure.io/fedora-qa/os-autoinst-distri-fedora

The actual test runs are here: https://openqa.fedoraproject.org/

Without tests and agreement by that SIG to support it at that level, I'm not going to commit to it either. We just don't have the resources for it.

For example, if @joshstrobl wants to make the Budgie SIG reach that level, I'm happy to support it at that level. Most desktops have not opted in that because it means essentially being on the hook for when the desktop breaks and stops the development and release process for a Fedora release.

Alternatively, we can build images for these desktops, we'll just need to communicate to the user that these may be less supported than GNOME and KDE Plasma in some meaningful way.

Personally, unless I have the hardware in hand to actually validate against, I'm hesitant to provide support for Budgie Desktop under any architecture other than x86_64. The fact Budgie compiles under other architectures (armv6, s390x, risc-v) is more accidental than intentional design, as we just happen to use libraries, toolkits, etc. that support them and don't write any code that'd be architecture-specific in nature.

I don't want to be on the hook for support of a desktop environment and its respective macrocosm on an hardware that is not easily accessible (from a financial perspective). Unless we're talking about the Mac Minis, the M2 Macbooks Pros which in my opinion are the more reasonable option with their 16GB of unified memory, start at 2500 EUR. I wouldn't really have a reason to use it otherwise (I have a work issued ThinkPad and a pretty beefy workhorse of a desktop), and I'd rather put that money into other places. I think the work that Asahi is doing is fantastic and I love seeing it evolve, it just isn't where most of our users would be at and the ROI wouldn't be there.

With regards to Budgie being a "release blocker", I don't believe all of Fedora should get tied up if it suddenly fails to compile or is in any other state that makes it less feasible to ship immediately (maybe sudden new Mutter ABI and/or (lib)gnome-desktop changes that need further testing and rework, or just straight up broken under X11). Both GNOME and KDE have a diverse group of people, from several companies, being paid to work on their respective ecosystems on a full-time basis, so they are able to drive more resources into fixing blockers than Budgie Desktop can (no full-time or part-time developers).

Ahhh ok, yeah there a number of considerations that need to be taken into account. In order to reach the release-blocker threshold, you really would need to have a team behind that project. The hardware cost is another major factor.
I suppose it's helpful to look at things from the perspective of the average user.
Thanks for that.