F39 proposal: Fedora Onyx (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Fedora_Onyx

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 ==
Creation of an official Fedora immutable variant with a Budgie Desktop
environment, complementing Fedora Budgie Spin and expanding the
immutable offerings of Fedora.

== Owner ==
* Name: [[User:joshstrobl| Joshua Strobl]]
* Primary Contact Person: [[User:joshstrobl| Joshua Strobl]]
* Email: joshstrobl(a)fedoraproject.org
* SIG: [[SIGs/Budgie|Budgie]]


== Detailed Description ==
Fedora Onyx is an immutable desktop operating system, featuring the
Budgie Desktop environment. Fedora Onyx leverages the same
foundational technologies as other Fedora immutable variants such as
Fedora Silverblue, Fedora Kinoite, and Fedora Sericea (flatpak,
rpm-ostree, podman, toolbx). Fedora Onyx is built for people that are
attracted to / find value in the Fedora computing platform and Budgie
Desktop environment, but need the robust immutability and atomic
capabilities that rpm-ostree provides, which are not be offered
through traditional Fedora spins (e.g. Fedora Budgie Spin).

Original change proposal for Fedora Budgie Spin: [[Changes/FedoraBudgie]]

== Feedback ==
No specific feedback received so far.



== Benefit to Fedora ==
Fedora Onyx will expand Fedora’s existing attractive offerings of
immutable operating systems, providing an on-ramp for potential users
to the Fedora platform, as well as a desired experience among current
Fedora Budgie Spin users that wish to experiment with rpm-ostree or
dive into tooling that pairs well with the immutable experience. By
actively building on and leveraging technologies adopted by similar
immutable variants from Fedora (Kinoite, Sericea, and Silverblue),
Fedora Onyx may help to strengthen those variants by putting more
contributors behind building and maturing our shared technologies.

== Scope ==

* Proposal owners:
** The Budgie SIG will submit Pungi changes needed to add this new
variant to the compose.
** The Budgie SIG will submit the changes to add a new sub-package to
fedora-release.
** The Budgie SIG will maintain the Onyx specific rpm-ostree config in
the workstation-ostree-config repo.
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issue/11411 #11411]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: Submitted as
[https://pagure.io/Fedora-Council/tickets/issue/451 #451]
* Alignment with Community Initiatives: N/A

== Upgrade/compatibility impact ==
N/A. Not a System Wide Change. ostree installations will be able to
seamlessly rebase to onyx in the same way they would any other
variant.


== How To Test ==
TBA. Instructions will be posted on Fedora Discussion upon landing of
the required components such as rpm-ostree config. These instructions
will follow similar steps as rebasing for any other rpm-ostree
variant.


== User Experience ==
N/A. No changes for existing Fedora users, including those using
Fedora Budgie Spin. Users of Fedora Onyx will receive a similar user
experience to Fedora Budgie Spin, with a smaller package set to
encourage users to more heavily leverage flatpak to curate their own
desired experience.

== Dependencies ==
N/A. Not a System Wide Change.

== Contingency Plan ==

* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), No


== Documentation ==
There may be known issues with other Fedora immutable variants which
may be addressed by existing documentation such as the
[https://docs.fedoraproject.org/en-US/fedora-silverblue/troubleshooting/
Fedora Silverblue Troubleshooting document].

== Release Notes ==
Fedora Onyx has been introduced as a new immutable variant of Fedora
Linux / Fedora Budgie Spin, featuring the Budgie Desktop environment
and the same robust technologies as our other variants such as
Kinoite, Sericia, and Silverblue (flatpak, rpm-ostree, podman,
toolbx).


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Zbigniew Jędrzejewski-Szmek]

On Mon, May 01, 2023 at 03:31:00PM -0400, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/Fedora_Onyx
>  == Detailed Description ==
>  Fedora Onyx is an immutable desktop operating system, featuring the
>  Budgie Desktop environment. Fedora Onyx leverages the same
>  foundational technologies as other Fedora immutable variants such as
>  Fedora Silverblue, Fedora Kinoite, and Fedora Sericea (flatpak,
>  rpm-ostree, podman, toolbx). Fedora Onyx is built for people that are
>  attracted to / find value in the Fedora computing platform and Budgie
>  Desktop environment, but need the robust immutability and atomic
>  capabilities that rpm-ostree provides, which are not be offered
>  through traditional Fedora spins (e.g. Fedora Budgie Spin).
>  
>  Original change proposal for Fedora Budgie Spin: [[Changes/FedoraBudgie]] 
I assume that this proposal will be accepted; the following is not
about blocking this proposal. But I wanted to ask a wider question:
is there some way to avoid having a separate immutable spin for each
and every desktop? The desktop is maybe a 100MB out of the whole distro,
and everything else is the same between the spins. For a package-based
install, a user would could just the generic variant and then configure
their account to use a different graphical shell. But here we need a
place on the download page, and in the docs, and we build ISO images,
run QA, etc., so there is a noticable cost to each new deliverable.

Zbyszek

[Neal Gompa]

On Thu, May 4, 2023 at 3:29 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Mon, May 01, 2023 at 03:31:00PM -0400, Ben Cotton wrote:
>  > https://fedoraproject.org/wiki/Changes/Fedora_Onyx
>  > == Detailed Description ==
>  > Fedora Onyx is an immutable desktop operating system, featuring the
>  > Budgie Desktop environment. Fedora Onyx leverages the same
>  > foundational technologies as other Fedora immutable variants such as
>  > Fedora Silverblue, Fedora Kinoite, and Fedora Sericea (flatpak,
>  > rpm-ostree, podman, toolbx). Fedora Onyx is built for people that are
>  > attracted to / find value in the Fedora computing platform and Budgie
>  > Desktop environment, but need the robust immutability and atomic
>  > capabilities that rpm-ostree provides, which are not be offered
>  > through traditional Fedora spins (e.g. Fedora Budgie Spin).
>  >
>  > Original change proposal for Fedora Budgie Spin: [[Changes/FedoraBudgie]]
>
>  I assume that this proposal will be accepted; the following is not
>  about blocking this proposal. But I wanted to ask a wider question:
>  is there some way to avoid having a separate immutable spin for each
>  and every desktop? The desktop is maybe a 100MB out of the whole distro,
>  and everything else is the same between the spins. For a package-based
>  install, a user would could just the generic variant and then configure
>  their account to use a different graphical shell. But here we need a
>  place on the download page, and in the docs, and we build ISO images,
>  run QA, etc., so there is a noticable cost to each new deliverable.
>  
If Anaconda boot ISOs could be extended so that you could select
Fedora RPM-OSTree and then select a different RPM-OSTree remote to
install, then that would mimic the workflow you expect. We could then
extend that toward having an install DVD with an RPM-OSTree repository
that contains all of the different desktops.

Unfortunately, we don't have that. :(



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Kevin Fenzi]

On Thu, May 04, 2023 at 07:28:29AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  
>  I assume that this proposal will be accepted; the following is not
>  about blocking this proposal. But I wanted to ask a wider question:
>  is there some way to avoid having a separate immutable spin for each
>  and every desktop? The desktop is maybe a 100MB out of the whole distro,
>  and everything else is the same between the spins. For a package-based
>  install, a user would could just the generic variant and then configure
>  their account to use a different graphical shell. But here we need a
>  place on the download page, and in the docs, and we build ISO images,
>  run QA, etc., so there is a noticable cost to each new deliverable. 
Yep. This same problem exists in the live media 'spins' space. 
(Although there it's harder because spins do some customization in
kickstarts, so if you start with one you may have a different setup from
another if you post install it).

I'd really like some solution to this too.

There is also the cost that all these different names cause: marketing,
support, etc.

kevin