EDIT: With the immensely greater wisdom that comes with being a day older, I'm now more or less convinced this whole post is wrong. But instead of editing it and confusing people who read the original, I've left it here and written a follow-up. Please read that.
Thanks to mizmo for inspiring this post.
Mo wrote that the Cloud WG has decided that, from Fedora 24 onwards, they will focus on Atomic-based images as their primary deliverables. In response to this, Mo and Matt Miller were kicking around the idea of - as I understand it - effectively rebranding the 'Cloud' flavor of Fedora as the 'Atomic' flavor.
This immediately struck me as problematic, and after a bit of thought I was able to identify why.
The current Fedora flavors - Cloud, Server, and Workstation - can be characterized as contexts in which you might want to deploy Fedora. "I want to deploy Fedora on a Cloud!", or "I want to deploy Fedora on a Workstation!", or "I want to deploy Fedora on a Server!" Yes, there's arguably a bit of overlap between 'Cloud' and 'Server', but we do have a reasonable answer to that ('Cloud' is about new-fangled cattle, 'Server' is about old-fashioned pets).
Atomic is not a context in which you might deploy Fedora. You can't say "I want to deploy Fedora on an Atomic!", it just doesn't work. Atomic is rather what I'm referring to as a deployment method. It's a mechanism by which the system is deployed and updated. Another deployment method - the counterpart to 'Atomic' - would be 'RPM'. Atomic happens to a deployment method that's quite appropriate for Cloud deployments, but that doesn't mean you can just do s/Cloud/Atomic/g and everything will make sense.
So for me the idea is simply not conceptually compatible with how we define the flavors. We might even, for instance, want to build 'Atomic Workstation' instances of Fedora. I believe there's even been interest in doing that, before.
Mo's post suggests that we might treat 'cloud' rather like we currently treat 'ARM', as a sort of orthogonal concept to the flavors, with a kind of parallel identity on the download site. I would suggest that it would make more sense to do exactly the opposite: it's Atomic that should be given a sort of parallel existence. We might want to have an Atomic landing page which focused on all the Atomic implementations of Fedora. But it's not, for me, a flavor.
So you might be aware, I have a little project called fedfind, which is broadly about finding Fedora media. About half of the work fedfind does is finding the media. The other half of the work it does is identifying them. Fedora 23 Beta RC1 has 59 'images', approximately (depending on whether you count boot.iso files separately from their hardlinked alternate names). Trying to come up with a set of attributes that would serve as a sort of conceptual framework for identifying images has been an interesting (and ongoing!) challenge. In fact, as a result of thinking about the 'Atomic' proposal, I've just revised fedfind's approach a little. So, I thought I'd write quickly about how fedfind does it.
I first thought about this stuff before starting fedfind, when I wrote an image naming policy. fedfind initially followed that policy precisely. Events have overtaken it a bit, though, so the current implementation isn't quite the same. And today, I've added the deployment method concept as an attribute in fedfind's system. The changes described here are sitting in my editor right now, but should show up in git master soon!
Some of the attributes fedfind uses are fairly obvious (arch is just the arch, and release, milestone and compose are just version identifiers), so I'll focus on the more interesting ones. fedfind provides a couple of properties - desc and shortdesc - for images which can be used as descriptions; taken together, all these properties allow us to give a unique identity to every one of the 59 images in 23 Beta RC1, as well as covering all historical releases (in my checks anyway). shortdesc contains payload, deployment (if not 'rpm'), imagetype, and imagesubtype (if present); desc adds arch. For any given release's images, there should be no duplicated descs.
These identify the 'type' of the image specifically. What's the difference between the Fedora 22 x86_64 Workstation live image and the Fedora 22 x86_64 Workstation network install image? They're the same version, same arch, same payload (see below) - but different imagetype. A few images also have an imagesubtype. For instance, we provide two types of Vagrant image, for use with libvirt and virtualbox; these have vagrant as the imagetype and libvirt or virtualbox as the imagesubtype.
It's intended that most every fedfind image should have either a flavor or a loadout; for convenience, whichever one it has is also available as the payload. This can be thought of as 'what's the actual content of the image'. Flavors are workstation, server, and cloud; loadouts are things like kde, xfce, mate etc. (for live images and ARM disk images), plus some oddballs. There is a minimal for ARM disk images, and source and desktop for older releases where we had source CDs/DVDs and 'Desktop' live images. There's one fairly special case: pre-Fedora.next DVDs and network install images, boot.isos, and current nightly images have no flavor or loadout, but have the special payload generic.
Current fedfind releases have a concept of subflavor, which is only used to give some Cloud images a subflavor of atomic. After thinking about this (above) it seemed completely wrong, so today I've changed things around so the subflavor property is gone, and instead we have...
As discussed above, this is the 'deployment method'. Currently it's either rpm or atomic.