I’m somewhat skeptical of the validity of this objective as a distinct artifact separate from our existing deliverables. “AI developer” in itself isn’t useful unless it’s clarified with a target subtype. There are other further decompositions that are important: are we talking about input refinement (data collection, training synthesis, etc.) or outcome oriented (model synthesis, RAG, etc.)? These are completely different.
Ehh…
I don’t think this is a useful change. Firstly, LTS kernels are almost exclusively used for development of components that aren’t integrated or supported upstream in any meaningful way. Not to mention, the complexity of supporting alternative kernels in Fedora software and update infrastructure is significant. And finally, it screws over our ability to coherently identify hardware support.
I should note that this doesn’t require (1) either. The OpenRM module works just fine with the latest kernel code. There are much more significant problems with kernel module packages (KMPs):
- The KMP infrastructure in Fedora is in very bad shape relative to other RPM distributions ever since we abandoned kmods 20 years ago.
- We don’t have tooling to do automatic rebuilds to chain KMPs to new kernel updates.
As a point of comparison, the SUSE folks have all this worked out and consequently are able to ship things like that much more easily. They have first-class support and automation because they’ve always been automation-centric whereas Red Hat/Fedora has historically been manpower-centric.
Also, I don’t think it’s a good idea for us to provide a driver that is effectively useless out of the box. We’re not distributing the required userspace components ourselves, and nobody bothered to hook up Mesa to OpenRM on Linux. That’s not to say this stuff shouldn’t be fixed: I think it should for the various community developed out of tree kernel modules that do work with fully open source stacks.
Finally, there is another issue changing our policy to support and endorse out of tree kmods in Fedora as KMPs: the likelihood our user’s systems will be considered tainted and ineligible for support from upstream kernel developers goes up significantly. Kernel developers prefer Fedora and Fedora users over others because of the existing state of things.
Ehh, okay? Not sure why it should be atomic, but whatever.
Are we equating AI = CUDA now? Because I think generally Fedora and Fedora affiliated initiatives should not do that. Regardless of the value proposition of the current crop of AI things, I would hope our goal should be to encourage full stack OSS for this. Of course, this is proposed as a Remix, so it strictly doesn’t matter here, but I definitely would not want this to be Fedora-endorsed because it sends a dark signal that we don’t care enough to push for open source driven AI technology stacks.
This cannot be resolved against the philosophy of Fedora contributors. I don’t really care about the legal issues, because having worked through them for another distribution, I know they are resolvable. But philosophically I feel this is against Fedora’s own mission. I would really not want this to be done.
First get Podman Desktop in Fedora. 
I have mixed feelings about this. A downside of this is that we’re not teaching people how to own the computing experience and have local ownership of their system. We’re also reinforcing opinionated setups over adaptable ones. An “appliance” workstation environment feels antithetical to me. But I know that there’s a lot of people really wanting this, so sure. But this also feels like Remix territory rather than Fedora territory.
With my FESCo hat on, I would signal pretty strongly against this. I don’t think there’s enough “meat” on those bones.
I also think your rationale for this is rather weak, since it isn’t even needed for OpenRM, and since you intend to go Atomic for your spin, you especially don’t need it since atomic images can choose to compose using the updates-archive repository and leverage cherry-picking of updates as they so please.
That image would need to drop the Fedora branding per our guidelines. I personally would be unhappy about a Fedora cobranded image with this given our philosophy as a project.
We are already doing this? There’s an AI/ML SIG, NeuroFedora, and other groups already focusing and iterating on that.
If I just scope this to the stuff I think we should do for this, it’s probably achievable in one Fedora release as a Change, since you’re basically making an opinionated spin that preloads a particular collection of software. The main gap is Podman Desktop isn’t in Fedora and that needs to be resolved. Adding Electron to Fedora is not much worse than the effort it took to add CEF, but someone has to be willing to keep up with it afterward. 
One of the problems Fedora has right now is that its primary sponsor and major employer of kernel hackers does not generally allocate their contributors to participate in Fedora. They don’t review Fedora bugs, they don’t assist users, they don’t help much with the Fedora kernel in general. It is telling that ARK and the kernel package actually define Fedora as the special case, rather than RHEL being the special case as the subset downstream. 
As a counterpoint, Btrfs in Fedora is well-supported because the Btrfs SIG has upstream Btrfs developers as part of the team and actively does work on that. When reports come in, they are triaged and responded to either within Fedora or upstream. The fact that we ship the latest stable kernels means that those fixes are delivered quickly too.
Nearly all of the other subsystems in the Linux kernel in Fedora simply do not have anywhere close to that kind of support. Not in power and memory management (over a decade of nobody fixing hibernate with lockdown!), not in block and other filesystems, not in graphics, not in networking, and not in anything else.
Before we start talking about adding kernels, we need people to care about the stuff people report now.