From Fedora Project Wiki
m (clarify naming options for existing variants)
Line 8: Line 8:


== Owner ==
== Owner ==
* Name/Email: [[User:Siosm| Timothée Ravier (siosm@fedoraproject.org)]], [[User:miabbott| Micah Abbott (miabbott@redhat.com)]]
* Name/Email: [[User:Siosm| Timothée Ravier (siosm@fedoraproject.org)]], [[User:miabbott| Micah Abbott (miabbott@redhat.com)]],  [[User:fale| Fabio Alessandro Locati (fale@fedoraproject.org)]]


== Current status ==
== Current status ==

Revision as of 09:58, 9 October 2023

Fedora Atomic Desktops

Important.png
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

We will regroup all desktop, rpm-ostree based variants of Fedora under the Fedora Atomic Desktops name. Each individual variant (Silverblue, Kinoite, Sericea, Onyx) will keep their name as is. While this is a Change Request, it is not addressed at FESCo but at the Fedora Council as this is not a technical change but a marketing / policy one.

Owner

Current status

  • Targeted release: Fedora Linux 40
  • Last updated: 2023-10-09
  • [<will be assigned by the Wrangler> devel thread]
  • Fedora Council issue: #361
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

The Fedora website currently uses the term "Immutable Desktops" to regroup all desktop, rpm-ostree based Fedora variants. The term "immutable" is confusing to users, has been the source of many confusion and does not accurately reflect the advantages of those variants.

Thus we want to regroup those variants under a "new" name. The advantage of the Atomic name is that it already was a brand in the past, and it’s both technically accurate, short, but non-descriptive and non-restrictive so that people would have pre-conceived ideas like with “immutable”.

We've created the Fedora Atomic Desktops SIG to co-ordinate across-variants work. One of the long term goals of this SIG is to work on making those variants the default option in Fedora, thus removing the need for a distinct name.

We will not require existing variants (Silverblue, Kinoite, Sericea, Onyx) to be renamed, as those brands already have some traction and history. It will be up to the decision of the SIGs if they want to rename the existing variants as a result of this change. We will not rename the ostree refs or do any technical changes related to this change to avoid costly and mostly useless or invisible work.

New variants will have the option of creating their own names or using the Fedora <Desktop> Atomic or Fedora Atomic (with) <Desktop> names. This will be up to each SIG. For example for XFCE: Fedora Vauxite, Fedora XFCE Atomic, Fedora Atomic (with) XFCE.

Note that both Fedora CoreOS and Fedora IoT will remain as is and will not be regrouped under this brand, which only focuses on desktops. Both CoreOS & IoT variants have a strong brand on their own and do not suffer from the immutable naming.

Feedback

A lot of other names have been suggested ("package mode", "image mode", "reprovisionable", "anti-hysteresis") but so far those are either "too technical", "too long" or "too ambiguous/imprecise".

Another suggested option was to rename all variants under the Silverblue name (Silverblue GNOME, Kinoite -> Silverblue KDE, etc.). This however creates too long names and would likely create confusion as user would expect all systems to share a Silverblue base, which is not the case.

References:

Benefit to Fedora

The main benefits are: less confusion for users / podcasters / reviewers, better branding / marketing.

Scope

  • Proposal owners: Submit / review pull-requests to update the name on the Fedora Website
  • Other developers: N/A
  • Release engineering: N/A
  • Policies and guidelines: N/A
  • Trademark approval: #361
  • Alignment with Community Initiatives: N/A

Upgrade/compatibility impact

No technical changes so not impact on users.

How To Test

Nothing to test beyond the website changes.

User Experience

This should not be noticeable by users from a technical perspective.

Dependencies

N/A

Contingency Plan

  • Contingency mechanism: Everything stays as is.
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? No

Documentation

We'll try to update the documentation and figure out a way to share more of the content between those variants.

Release Notes

To be done.