...and make it official!

[xynydev]

First of all, thanks a lot for @gmpinder to taking the initiative on this. (and apologies for being mostly absent recently)

I feel like there's some questions that still need discussion and documentation, so let me put the ball rolling.

1. Scope

This is the most important one.

1.1. Image count

Things to consider are:

• How many base images do we want to maintain?
• Who will maintain them?
• Can we guarantee stable and quality base images if we don't dogfood all of them as developers?

If we want our base images to be a dependable and well-supported base for our users without relying on the assumption that a community will step up to do maintenance for us, the scope should be limited to a small set of images. This could mean only Fedora images with only official Fedora-supported desktop environments (atomic desktops).

If we want our base images to be a rich jumping-off point not meant to be dependable or fully supported as-is, and we want to prioritize diversity, we may feel free to add base images built on top of other distros or niche desktop environments as we feel, and also feel free deprecate and remove them when they stop working. In this case, we should document the active maintenance effort going into each image and designate a set of mostly popular images as well-supported core images (say silverblue, kinoite, cosmic, and base, but those are subject to change if others become more popular).

A hybrid approach could be having the limited small set of images be the only published ones, with us maintaining a module or something to allow users to port the improvements made in our base images to other images.

1.2. Image content

As we know, the contents of the ublue base images have been the topic of debate. Some maintainers say that the scope was too wide in the beginning, but stuff that was added back then can't be removed now, which causes confusion among new contributors seeking to add something into the image based on the scope perceived from the package list and not the actual scope enforced by maintainers.

We have the advantage of starting fresh without baggage. We can still define before implementing everything.

Things that might be included in the scope (right now)

• Tools that often come out of the box and might be expected to be included by many users (ex. vim, tmux, htop, fzf)
• Hardware enablement (ex. Nvidia drivers, udev rules)
• Essentials for image-based Linux (ex. bootc, distrobox)
• Obscure stuff that makes the OS work as expected (ex. codecs, thumbnailers)
• Fixing other instances of Fedora being Fedora (ex. replacing Fedora Flatpaks repo with Flathub)
• Stuff you don't know you need until you really do (ex. coreos-sulogin-force-generator)
• Nice-to-have things that just add to QoL (ex. just, lshw, wl-clipboard)

Things to exclude?

• POSIX tools rewritten in Rust ™️ (ex. exa, bat)
• Other custom shell stuff (ex. starship, fish)
• Purely cosmetic things (ex. a boatload of fonts, wallpapers, custom loading screen logos)
• Programs with a specific obscure use-case that might not be for everyone "bloat" (ex. firefoxpwa, nix, framework_tool)
• Footguns (ex. chsh)

Some of these may be hard to draw boundaries around, and especially with QoL tools we have to be careful since QoL is such a broad definition that almost everything is included in it right now.

2. Relationship to current Universal Blue base images

This is mostly a documentation issue.

Questions to answer

• What issues did we have with the Universal Blue base images to end up building our own?
• How should someone looking to build their own image decide between ublue and BlueBuild base images?
  • Universal Blue is a bigger community, but they will probably not provide support for BlueBuild base image users, instead directing them towards our smaller community
  • What are the concrete improvements from using BlueBuild base images that justify using the offering with a smaller community behind it right now?
  • Should I just use BlueBuild base images when building with BlueBuild and use ublue images when building with their image-template, or would image-template users benefit from switching as well?

3. Base images to use (for Fedora)

For future notice.

We're currently using quay.io/fedora-ostree-desktops which is both unofficial and experimental. The repo is currently called ci-test and maintained by Timothée.

Whispers from the Universal Blue discord indicate, though, that this effort might soon be transformed into a "Base Images 2.0" for Universal Blue. "Fedora Remix Bootable Container images" or such. This would probably retain the same old stability of the images with not much of a scope change, but then we have to come to terms with the fact that our "ublue base image alternative" is now based on the ublue base images.

Other option is fedora-bootc. I know it's way more minimal, but it's also official. May be too much effort maintaining desktop environment spins on top of that.

4. When is this experiment going to turn into something stable that we can recommend and market everywhere?

This is a question I have for you all.

Agreeing on a scope, sure, that might be a good start. Are there some other concrete steps that have to be taken?

[gmpinder]

So far I feel like I'm in line with most of what is in here. Though I would like to say that I think we should have base images for other distributions based off of bootcrew where we can. I think widening our base would give users a lot more choice in how they want to build their images.

I'd be fine with switching to the official fedora bootc image and trying to update the recipe to get to the same feature parity as the current ostree desktop-based images.

Can we guarantee stable and quality base images if we don't dogfood all of them as developers?

I do believe this is going to be a bit of a bottleneck for us. I think it's kind of inevitable that we're going to need community involvement with this project, especially since it is just a volunteer level project. But hopefully if we keep things minimal as much as we can, it'll be easier for us to maintain.

I think when it comes to the universal blue images versus our images, it comes down to the user's choice. I think we should encourage users to use our base images to start, but at the end of the day, it is up to the user to decide what image they want to use.