├── README.md └── rfcs ├── 0000-template.md ├── 0001-build-fedora-epel-for-almalinux-and-almalinux-kitten-x86_64_v2.md ├── 0002-enable-kvm-on-almaLinux-9-on-ppc64le.md ├── 0003-use-dynamic-workspace-indicator-on-gnome.md ├── 0004-build-and-ship-nvidia-drivers.md ├── 0005-enable-btrfs-as-tech-preview.md └── 0006-enable-crb-on-almalinux-10.md /README.md: -------------------------------------------------------------------------------- 1 | # AlmaLinux ALESCo RFCs (Request for Comments) 2 | 3 | Welcome to the AlmaLinux Engineering Steering Committee's (ALESCo) RFC repository. This repository is the central place for proposing, discussing, and documenting significant changes to AlmaLinux. 4 | 5 | ## Table of Contents 6 | 7 | - [Introduction](#introduction) 8 | - [When to Submit an RFC](#when-to-submit-an-rfc) 9 | - [RFC Process Overview](#rfc-process-overview) 10 | - [How to Submit an RFC](#how-to-submit-an-rfc) 11 | - [RFC Lifecycle](#rfc-lifecycle) 12 | - [RFC Template](#rfc-template) 13 | - [Contributing Guidelines](#contributing-guidelines) 14 | - [Code of Conduct](#code-of-conduct) 15 | - [License](#license) 16 | - [Contact](#contact) 17 | - [Additional Notes](#additional-notes) 18 | - [Frequently Asked Questions](#frequently-asked-questions) 19 | - [How long is the review period?](#how-long-is-the-review-period) 20 | - [Who decides whether an RFC is accepted?](#who-decides-whether-an-rfc-is-accepted) 21 | - [Can I withdraw my RFC?](#can-i-withdraw-my-rfc) 22 | 23 | ## Introduction 24 | 25 | The AlmaLinux RFC process is a formal way to propose significant changes, enhancements, or new features to the AlmaLinux project. It aims to foster open collaboration, transparency, and comprehensive documentation of decisions made by ALESCo and the broader community. 26 | 27 | ## When to Submit an RFC 28 | 29 | Consider submitting an RFC if you are proposing: 30 | 31 | - Major changes to the operating system or its components. 32 | - EX, Changing the default desktop environment 33 | - New features or functionalities. 34 | - EX, Adding SPICE support 35 | - Any change that requires community consensus or impacts a large portion of the project. 36 | - EX, Replacing the use of OpenSSL with LibreSSL 37 | 38 | For minor issues like bug fixes or small enhancements, please use the appropriate [AlmaLinux issue tracker](https://bugs.almalinux.org/) or contribute directly to the relevant repository. 39 | 40 | ## RFC Process Overview 41 | 42 | 1. **Proposal Drafting**: Author drafts the RFC using the provided template. 43 | 2. **Submission**: RFC is submitted as a pull request to this repository. 44 | 3. **Accepted for Discussion**: Community and ALESCo members provide feedback, with active revision of the proposal expected. 45 | As part of this step, ALESCo will also send an email to the AlmaLinux OS Foundation board with a link to the RFC pull request, indicating whether or not the board input is expected to be a blocker for the vote. 46 | 5. **Final Comment Period (FCP)**: A last call for comments before the decision. The board will also get a notification of an impending vote here, in case they would like to provide input. 47 | 6. **Decision Making**: ALESCo votes on the RFC. 48 | 7. **Implementation**: Accepted RFCs are merged and scheduled for implementation. 49 | 50 | ## AlmaLinux OS Foundation Board input as a blocker 51 | 52 | In very rare circumstances the AlmaLinux OS Foundation Board will be required to provide input in things ALESCo is deciding on. In some cases the board may be required to approve a change, and in some cases they can abstain from an official position. However, as part of their oversight in the project, input will be required before a vote can be held in the following situations. 53 | 54 | * Input from the board will be a blocking stakeholder before ALESCo can vote on RFCs that... 55 | - involve a change to trademarks 56 | - involve a significant increase in needed resources 57 | - involve a new or expanded partnership of some kind 58 | 59 | To ensure the board provides input, the current board chair will be added as a required reviewer to the pull request. A representative from the board will also attend the meeting where the vote is taking place. 60 | 61 | As a note - this is not a veto right, but is only to ensure that the board has been able to advise ALESCo on any potential impacts of changes. 62 | 63 | ## How to Submit an RFC 64 | 65 | 1. **Fork the Repository**: Click the "Fork" button at the top-right corner of this page to create your own copy of the repository. 66 | 2. **Create a New Branch**: In your forked repository, create a new branch for your RFC: 67 | 68 | ```bash 69 | git checkout -b rfc-title-of-your-proposal 70 | ``` 71 | 72 | 3. **Copy the Template:** Copy the `0000-template.md` to `rfcs/XXXX-title-of-your-proposal.md`, replacing `XXXX` with the next available RFC number (use `0000` for the initial PR; the number will be assigned during the process). 73 | 4. **Write the RFC:** Fill out the template with your proposal. Be thorough and clear. 74 | 5. **Submit a Pull Request:** Push your branch to your fork and submit a pull request to this repository's main branch. 75 | 6. **Engage in Discussion:** Monitor the pull request comments and participate in the discussion, making revisions as necessary. 76 | 77 | ## RFC Lifecycle 78 | 79 | The RFC process has the following states: 80 | 81 | 0. **Submitted**: The RFC is submitted and requires an initial review for formatting, etc. Once it has been confirmed to meet the needs of the RFC process, the "accepted for discussion" tag will be added. 82 | 1. **Open for discussion**: The RFC is under initial and active discussion and may undergo several revisions. 83 | 2. **FCP (Final Comment Period)**: ALESCo announces an FCP, signaling that the decision will be made soon. When the RFC enters this stage, the "vote at next meeting" tag will be added. 84 | 3. **Accepted**: The RFC is approved and merged. 85 | 4. **Rejected**: The RFC is not approved; reasons are documented. 86 | 5. **Withdrawn**: The RFC is withdrawn by the author. 87 | 6. **Superseded**: The RFC is replaced by a new proposal. 88 | 89 | ## RFC Template 90 | 91 | The RFC template can be found [here](/rfcs/0000-template.md). Please use this template for all new RFCs. 92 | 93 | ## Contributing Guidelines 94 | 95 | * **Clarity:** Write clear and concise proposals. 96 | * **Respect:** Be respectful in discussions; adhere to the Code of Conduct. 97 | * **Responsiveness:** Be available to answer questions and provide clarifications during the review process. 98 | * **Documentation:** Update your RFC based on feedback received. 99 | 100 | ## Code of Conduct 101 | 102 | All participants are expected to uphold the AlmaLinux Code of Conduct. 103 | 104 | Which amounts to: be nice, be respectful, and be nerdy. 105 | 106 | ## License 107 | 108 | By contributing to this repository, you agree that your contributions will be licensed under the Creative Commons Attribution Share Alike 4.0 International (CC-BY-SA-4.0`). 109 | 110 | ## Contact 111 | 112 | * **Chat:** [AlmaLinux Mattermost](https://chat.almalinux.org/~alesco) 113 | * **Forums:** [AlmaLinux Community Forums](https://forums.almalinux.org/) 114 | * **Mailing List:** [devel@lists.almalinux.org](https://lists.almalinux.org/mailman3/lists/devel.lists.almalinux.org/) 115 | 116 | # Additional Notes 117 | 118 | * **Assigning RFC Numbers:** RFC numbers are assigned by the repository maintainers when the pull request is labeled as "accepted for discussion." Use 0000 as the number in your initial submission. 119 | * **File Naming Convention:** Name your RFC file as XXXX-title-of-your-proposal.md, where XXXX is the assigned RFC number. 120 | * **Directory Structure:** All RFC files should be placed in the rfcs/ directory. 121 | * **Updating RFC Status:** The status of the RFC should be updated in the document header as it progresses through the lifecycle stages. 122 | 123 | # Frequently Asked Questions 124 | 125 | ## How long is the review period? 126 | The standard review period is two weeks, but it can be extended if necessary to ensure adequate discussion. 127 | 128 | ## Who decides whether an RFC is accepted? 129 | The final decision is made by ALESCo, taking into account community feedback and the overall impact on the project. There is no obligation for the RFC to be accepted by the committee. 130 | 131 | ## Who is responsible for implementing an RFC once it's accepted? 132 | 133 | It is expected that contributors will be responsible for all or part of the work implementing the RFC. 134 | 135 | ## Can I withdraw my RFC? 136 | Yes, you can withdraw your RFC at any point before it is accepted by closing the pull request and stating your intention. 137 | -------------------------------------------------------------------------------- /rfcs/0000-template.md: -------------------------------------------------------------------------------- 1 | # RFC: [Title of the RFC] 2 | 3 | * **RFC Number:** `XXXX` (Assigned by the repository maintainers) 4 | * **Author(s):** [Your Name and Contact Information] 5 | * **Status:** Draft 6 | * **Created:** [YYYY-MM-DD hh:mm UTC] 7 | * **Updated:** [YYYY-MM-DD hh:mm UTC] 8 | 9 | ## Abstract 10 | 11 | A short summary of the proposal. 12 | 13 | ## Motivation 14 | 15 | * **Problem Statement:** Describe the issue or need that the proposal addresses. 16 | * **Goals:** What do we aim to achieve with this change? 17 | 18 | ## Detailed Design 19 | 20 | * **Proposal Details:** Provide an in-depth explanation of the proposed changes. 21 | * **Implementation Plan:** Outline the steps required to implement the proposal. 22 | * **Compatibility:** Discuss the impact on existing systems or processes. 23 | 24 | ## Drawbacks 25 | 26 | List potential downsides or trade-offs of the proposal. 27 | 28 | ## Benefit to AlmaLinux 29 | 30 | Explain what benefits the proposal brings to AlmaLinux (community support, marketing opportunities, etc.). 31 | 32 | ## Scope 33 | 34 | * **Proposal Owners:** 35 | * **Other Developers:** 36 | * **Policies and guidelines:** N/A 37 | * **Trademark approval:** N/A 38 | 39 | ## Unresolved Questions 40 | 41 | Identify any open issues or areas needing further investigation. 42 | 43 | ## Acknowledgments 44 | 45 | Credit individuals who contributed to the RFC. 46 | -------------------------------------------------------------------------------- /rfcs/0001-build-fedora-epel-for-almalinux-and-almalinux-kitten-x86_64_v2.md: -------------------------------------------------------------------------------- 1 | # RFC: Build Fedora EPEL for AlmaLinux and AlmaLinux Kitten x86_64_v2 2 | 3 | * **RFC Number:** `0001` 4 | * **Author(s):** [Jonathan Wright](jonathan@almalinux.org), [Neal Gompa](ngompa@almalinux.org), [Andrew Lukoshko](alukoshko@almalinux.org) 5 | * **Status:** Accepted 6 | * **Created:** [2025-01-29 16:00 UTC] 7 | * **Updated:** [2025-03-05 21:00 UTC] 8 | 9 | ## Abstract 10 | 11 | Rebuild Fedora's EPEL (Extra Packages for Enterprise Linux) to support x86_64_v2 in AlmaLinux 10, and AlmaLinux Kitten 10. ALESCo unanimously approved a proposal to rebuild AlmaLinux 10 for x86_64_v2 as an additional architecture on 2024-07-24 in the first [meeting](https://wiki.almalinux.org/alesco/meeting-minutes/2024-07-24.html). 12 | 13 | ## Motivation 14 | 15 | * **Problem Statement:** Users of AlmaLinux expect to have access to content provided by Fedora EPEL on all architectures that AlmaLinux itself is available on. The x86_64_v2 variant is not available in upstream CentOS or RHEL and thus not available from Fedora EPEL, which impairs the usefulness of AlmaLinux 10 on x86_64_v2 systems. 16 | * **Goals:** The x86_64_v2 variant should be as functional and useful as any other architecture AlmaLinux 10 is offered with the availability of EPEL content. 17 | 18 | ## Detailed Design 19 | 20 | * **Proposal Details:** Provide an in-depth explanation of the proposed changes. 21 | * Pull changes/updates from upstream EPEL daily and rebuild the packages. These built-packages will go into a dedicated repository which users can enable using `dnf install epel-release` just as in current AlmaLinux 8/9. 22 | * No changes to EPEL packages will be permitted downstream. Any changes needed to build in AlmaLinux for alternative architectures needs to be contributed to Fedora. We will build directly from Fedora SRPMS fetched via Bodhi composes. 23 | * We got feedback from the EPEL steering committee whose main concern was naming confusion. We will name the actual package providing the repo `epel-release-almalinux-altarch` and make it `Provides` and `Conflicts` with `epel-release`. This package will only be available in the extras repo for architectures not served by Fedora. 24 | * Packages we rebuild and publish will have `.alma_altarch` added to their disttag for easy identification. 25 | * These packages will use a dedicated GPG signing key - not the base AlmaLinux OS package key. 26 | * The repository will be an optional rsync target for mirror owners and require them to configure mirroring for it. 27 | * Branching has changed in EPEL 10 versus older EPEL releases. EPEL 10 will be branched for minor releases and have a running `epel10` branch targeting CentOS Stream (and later RHEL 10.10). 28 | * The `epel10` branch is used to create builds for the leading EPEL 10 minor version repository. Prior to the CentOS Stream 10 end of life (which corresponds to the end of the RHEL 10 [Full Support Phase](https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates)), these builds are built against external repositories of the matching major version of CentOS Stream 10. 29 | * These builds will indicate the minor version they are targeting in their [dist tag](https://docs.fedoraproject.org/en-US/packaging-guidelines/DistTag/) using the format of .el10_x, where x is the minor version. They are published in the pub/epel/10 dnf repository for consumption by CentOS Stream 10. 30 | * After CentOS Stream 10's end of life, these will be built against RHEL 10.10. 31 | * The `epel10.x` branches (where x is the minor version, e.g. epel10.0) are used to create builds for the trailing EPEL 10 minor version repositories. These builds are built against external repositories of the matching minor version of RHEL 10. 32 | * These builds will indicate the minor version they are targeting in their [dist tag](https://docs.fedoraproject.org/en-US/packaging-guidelines/DistTag/) using the format of .el10_x, where x is the minor version. They are published in pub/epel/10.x dnf repositories for consumption by the corresponding RHEL 10 minor version. 33 | * Source: https://docs.fedoraproject.org/en-US/epel/branches/#_epel_10 34 | * We will maintain builds for two branches, `epel10` (for AlmaLinux Kitten) and `epel10.x` for the currently supported AlmaLinux/RHEL release. `epel10.x` for old minor releases will be moved to vault. 35 | * **Implementation Plan:** We will ask Fedora Bodhi for the latest built package in stable, grab its SRPM, and build it. ALBS "platforms" will be used to handle the multiple stable targets. 36 | * **Compatibility:** This is a self-contained change proposal. Usage of this EPEL rebuild would remain optional and be disabled by default - just as upstream EPEL is within AlmaLinux already. 37 | 38 | ## Drawbacks 39 | 40 | * The x86 builders will have more work building packages. After the initial build this shouldn't be of any significant concern. 41 | * Potential confusion between AlmaLinux's rebuild and upstream EPEL. 42 | * More disk space required on mirrors that choose to mirror our EPEL rebuild. 43 | * Extra work on the Core SIG. 44 | 45 | ## Benefit to AlmaLinux 46 | 47 | This helps position AlmaLinux 10 x86_64_v2 on equal footing with the main AlmaLinux, and other EL builds which default to x86_64 v3. Potential users of the x86_64_v2 variant have expressed reluctance to use AlmaLinux without EPEL being available. EPEL is of large value to EL users in general and keeping it available to our x86_64_v2 users is important. 48 | 49 | This also lays the groundwork for future alternative architecture work, as EPEL is an important aspect for delivering AlmaLinux on architectures that upstream CentOS does not support. 50 | 51 | ## Scope 52 | 53 | * **Proposal Owners:** 54 | * Design and guidance on implementation 55 | * Creation of `epel-release-almalinux-altarch` package 56 | * **Other Developers:** 57 | * Deploy and enable the EPEL builds for alternative architectures (Core SIG). 58 | * **Policies and guidelines:** N/A 59 | * **Trademark approval:** N/A 60 | 61 | ## Acknowledgments 62 | * Alex Iribarren 63 | * Javier Hernandez 64 | * Ben Thomas 65 | -------------------------------------------------------------------------------- /rfcs/0002-enable-kvm-on-almaLinux-9-on-ppc64le.md: -------------------------------------------------------------------------------- 1 | # RFC: Enable KVM on AlmaLinux 9 on ppc64le 2 | 3 | * **RFC Number:** `0002` 4 | * **Author(s):** [Lance Albertson](lance@osuosl.org) 5 | * **Status:** Accepted 6 | * **Created:** [2025-02-14 17:25 UTC] 7 | * **Updated:** [2025-02-14 17:25 UTC] 8 | 9 | ## Abstract 10 | 11 | This RFC proposes enabling Kernel-based Virtual Machine (KVM) hypervisor support 12 | on AlmaLinux 9 for the ppc64le architecture. 13 | 14 | ## Motivation 15 | 16 | * **Problem Statement:** 17 | 18 | * Red Hat Enterprise Linux (RHEL) 9 removed support for KVM on the ppc64le 19 | architecture due to various technical challenges and resource allocation 20 | [priorities](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/considerations_in_adopting_rhel_9/index#ref_changes-to-kvm_assembly_virtualization). 21 | 22 | * **Goals:** 23 | 24 | * Reintroduce KVM support on AlmaLinux 9 for ppc64le. 25 | * Ensure compatibility and stability for users running virtual machines on IBM Power Systems. 26 | * Support OpenStack cloud users who need KVM for their cloud infrastructure 27 | 28 | ## Detailed Design 29 | 30 | * **Proposal Details:** 31 | 32 | * Kernel and QEMU Updates 33 | 34 | * Create AlmaLinux Kernel with KVM hypervisor support enabled for ppc64le 35 | * Update QEMU and other related packages to include the necessary patches 36 | and configurations for KVM support on ppc65le. 37 | * Testing and Validation 38 | 39 | * Conduct extensive testing to ensure stability and performance including 40 | running various workloads and tests on bare-metal IBM Power Systems. 41 | * Conduct extensive testing with OpenStack and it's underlying components 42 | to ensure stability and compatibility 43 | * Documentation 44 | 45 | * Provide comprehensive documentation to guide users on setting up and 46 | using KVM on ppc64le with AlmaLinux 9. 47 | 48 | * **Implementation Plan:** 49 | 50 | * Package Updates: Update the kernel and QEMU packages in the AlmaLinux 51 | repositories. 52 | * Testing: Perform rigorous testing on different IBM Power Systems 53 | configurations with OpenStack integration 54 | * Release: Roll out the updated packages, repository and documentation to the 55 | AlmaLinux community. 56 | 57 | * **Compatibility:** 58 | 59 | * Ensure that the updated packages and repositories do not interfere with 60 | existing AlmaLinux packages and repositories. 61 | 62 | ## Drawbacks 63 | 64 | * Additional maintenance and support required for the ppc64le architecture. 65 | 66 | ## Benefit to AlmaLinux 67 | 68 | * Community Support: Address the needs of users who rely on KVM for virtualization on IBM Power Systems. 69 | * Marketing Opportunities 70 | 71 | * Position AlmaLinux as a versatile and robust alternative to RHEL, attracting more users and contributors. 72 | 73 | ## Scope 74 | 75 | * **Proposal Owners:** 76 | 77 | * Design and guidance on implementation 78 | * Patch updates for kernel and QEMU packages 79 | * Testing on bare-metal systems 80 | * Ongoing maintenance and issues that may come up 81 | * **Other Developers:** 82 | 83 | * Assistance with ensuring changes made follow AlmaLinux developers guidelines 84 | * **Policies and guidelines:** N/A 85 | * **Trademark approval:** N/A 86 | 87 | ## Unresolved Questions 88 | 89 | * My initial testing showed some issues using qemu-kvm by default doesn't work and requires adding additional flags to 90 | work properly. I will need to do more testing and research to figure out why this is the case. 91 | 92 | ## Acknowledgments 93 | 94 | * Jonathan Wright 95 | -------------------------------------------------------------------------------- /rfcs/0003-use-dynamic-workspace-indicator-on-gnome.md: -------------------------------------------------------------------------------- 1 | # RFC: Use dynamic workspace indicator on GNOME 2 | 3 | * **RFC Number:** `0003` 4 | * **Author(s):** [Elkhan Mammadli](elkhan@almalinux.org), 5 | * **Status:** Accepted 6 | * **Created:** [2025-04-02 14:00 UTC] 7 | * **Updated:** [2025-05-30 01:00 UTC] 8 | 9 | ## Abstract 10 | 11 | Do not replace the dynamic workspace indicator with AlmaLinux OS logo as a part of branding. 12 | 13 | ## Motivation 14 | 15 | * **Problem Statement:** [GNOME 45](https://release.gnome.org/45) introduced a [dynamic workspace indicator](https://release.gnome.org/45/activities-loop.webm) that replaced the "Activities" button. This indicator shows the number of workspaces and enables switching between them via mouse scrolling. Although the GNOME version on AlmaLinux OS 10 is 47, the dynamic workspace indicator is visually replaced by the AlmaLinux OS logo. Which means switching between the workspaces still possible via mouse scrolling on the AlmaLinux logo. 16 | * **Goals:** For a complete experience, the dynamic workspace indicator should be consistent with GNOME's implementation. 17 | 18 | ## Detailed Design 19 | 20 | * **Proposal Details:** Do branding without replacing the dynamic workspace indicator. 21 | * **Implementation Plan:** 22 | - Implement a new patch for `gnome-shell` package to include AlmaLinux OS logo on the left side of the dynamic workspace indicator. 23 | - Automate the replacement of the branding upstream patch with the proposed one. 24 | * **Compatibility:** Since AlmaLinux OS 10 not released yet. This change only affects the AlmaLinux OS Kitten 10. 25 | 26 | ## Drawbacks 27 | 28 | N/A 29 | 30 | ## Benefit to AlmaLinux 31 | 32 | This will improve the overall GUI experience for users familiar with GNOME from other distributions, including CentOS Stream 10, Fedora, and Ubuntu. 33 | 34 | ## Scope 35 | 36 | * **Proposal Owners:** 37 | * Implementation and testing of the proposed patch. 38 | * **Other Developers:** 39 | * Core SIG 40 | * Automation of building and releasing of `gnome-shell` package. 41 | * **Policies and guidelines:** N/A 42 | * **Trademark approval:** N/A 43 | 44 | ## Unresolved Questions 45 | 46 | N/A 47 | 48 | ## Acknowledgments 49 | 50 | * [Neal Gompa](ngompa@almalinux.org) 51 | * [Javier Hernández](javi@almalinux.org) 52 | -------------------------------------------------------------------------------- /rfcs/0004-build-and-ship-nvidia-drivers.md: -------------------------------------------------------------------------------- 1 | # RFC: Build NVIDIA Open Source Drivers and Ship Repo Config for AlmaLinux 2 | 3 | * **RFC Number:** `0004` 4 | * **Author(s):** [Jonathan Wright](jonathan@almalinux.org), [Neal Gompa](ngompa@almalinux.org) 5 | * **Status:** Approved 6 | * **Created:** [2025-05-07 15:00 UTC] 7 | * **Updated:** [2025-05-07 15:00 UTC] 8 | 9 | ## Abstract 10 | 11 | Build and ship NVIDIA's open source graphics drivers. The kernel module should be signed for secure boot using a separate secure boot key under the AlmaLinux secure boot CA. Ship a repo config to pull cuda and userspace components from Nvidia's own repositories. 12 | 13 | ## Motivation 14 | 15 | * **Problem Statement:** Graphics drivers have always been a pain point for users in Linux and with GPUs now being used for more than just graphics, the pain is more real than ever. Currently users must search around the web to find the drivers they want, unsure if the components they find will work seamlessly together or not. We can and should solve this problem. 16 | * **Goals:** The modules/drivers and repo configs shipped should permit users to have a relatively seamless experience with NVIDIA GPUs within AlmaLinux, with only a few `dnf` commands required to get up and running with fully supported drivers. 17 | 18 | ## Detailed Design 19 | 20 | * **Proposal Details:** Provide an in-depth explanation of the proposed changes. 21 | * Build Nvidia's open source driver as a kmod. The legacy proprietary driver is out of scope for this. 22 | * It will be signed for secure boot using a dedicated secondary certificate that will be trusted by AlmaLinux kernel builds. 23 | * Ship a repo configuration file to pull user space and CUDA drivers from NVIDIA's dedicated repository. This is required due to the licenses from NVIDIA. 24 | * Initially, this will leverage the negativo17.org NVIDIA userspace driver repository and migrate to the official NVIDIA driver repository later. 25 | * This RFC plans support specifically for AlmaLinux 10 initially (including Kitten), with AlmaLinux 9 to follow. Support for AlmaLinux 8 is unlikely to happen without immense demand to justify the amount of backporting required to make it feasible. 26 | * Initially only the latest supported branch of the NVIDIA driver will be shipped and supported, though the implementation leaves room for multiple version trees to exist simultaneously. 27 | * **Implementation Plan:** The binary RPMs built will exist in their own, optionally enabled, repository. The release package to enable the repository will exist in the Extras repository (which is enabled by default), so that a single command could turn on everything required to then require only one more command to install the driver and associated userspace utilities. 28 | * **Compatibility:** This is a self-contained change proposal. Usage of the NVIDIA driver repository would remain optional. 29 | 30 | ## Drawbacks 31 | 32 | * None known at this time - The use of these packages will remain optional. 33 | 34 | ## Benefit to AlmaLinux 35 | 36 | AlmaLinux will become more accessible to users of NVIDIA GPUs - from small home users to HPC users alike, and everyone in between. The ability to run the GPU drivers and use secure boot will increase security in environments, and may allow further adoption of AlmaLinux in environments that it cannot currently be deployed due to regulatory restrictions around secure boot being disabled. 37 | 38 | ## Scope 39 | 40 | * **Proposal Owners:** 41 | * Design and guidance on implementation 42 | * Creation of `nvidia-open-kmod` package 43 | * Creation of `almalinux-release-nvidia-driver` package 44 | * **Other Developers:** 45 | * Key holders 46 | * Creation of NVIDIA driver secure boot certificates 47 | * Core SIG members 48 | * Adding public certificate to AlmaLinux kernel builds 49 | * Build environment setup for building `nvidia-open-kmod` with signed kernel modules 50 | * **Policies and guidelines:** N/A 51 | * **Trademark approval:** N/A 52 | 53 | ## Acknowledgments 54 | -------------------------------------------------------------------------------- /rfcs/0005-enable-btrfs-as-tech-preview.md: -------------------------------------------------------------------------------- 1 | # RFC: Enable Btrfs as a tech preview 2 | 3 | * **RFC Number:** `0005` (Assigned by the repository maintainers) 4 | * **Author(s):** [Michel Lind](michel@meta.com) 5 | * **Status:** Accepted 6 | * **Created:** [2025-05-08 20:36 UTC] 7 | * **Updated:** [2025-06-02 21:22 UTC] 8 | 9 | ## Abstract 10 | 11 | Btrfs is enabled as a tech preview for AlmaLinux 10 12 | 13 | ## Motivation 14 | 15 | * **Problem Statement:** CentOS Stream and Enterprise Linux distributions based on it, including AlmaLinux, currently lack Btrfs support - it is disabled in the kernel, and installer support and a lot of userspace tooling are missing. This makes the barrier of entry for using these distributions higher in organizations that have standardized on Btrfs. 16 | 17 | * **Goals:** 18 | * Ship Btrfs as a kernel module 19 | * Offer Btrfs as an option in the installer 20 | * Ship the utilities needed to manage Btrfs 21 | 22 | ## Detailed Design 23 | 24 | * **Proposal Details:** 25 | The kernel enablement should be self-explanatory. 26 | 27 | For the installer, we can reference what Fedora did when enabling Btrfs (minus setting it to be the default) 28 | 29 | * [Btrfs by default](https://fedoraproject.org/wiki/Changes/BtrfsByDefault) 30 | * [Btrfs transparent compression](https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression) 31 | * [Fedora Cloud Btrfs by default](https://fedoraproject.org/wiki/Changes/FedoraCloudBtrfsByDefault) 32 | * [/var on subvolume for immutable variants](https://fedoraproject.org/wiki/Changes/VarSubvol4SilverblueKinoite) - relevant to AlmaLinux derivatives that want to ship an immutable distro using Btrfs 33 | 34 | Utilities - apart from `btrfs-progs` which got added to EPEL because of a Golang dependency, EPEL can't host `btrfs` utilities because they will not be functional out of the box. And for compatibility reason AlmaLinux does not ship EPEL enabled by default anyway. So these will likely need to be branched and built for AlmaLinux. Looking at what CentOS Hyperscale SIG ships that are Btrfs related might be relevant here. 35 | 36 | * **Implementation Plan:** 37 | * update kernel config to enable Btrfs in AlmaLinux Kitten 38 | * undo installer changes in Anaconda and its dependencies that disables Btrfs support. Can leverage the CentOS Hyperscale SIG packaging to avoid duplicating work. 39 | * undo disabled btrfs in various userspace packages 40 | * import userspace utilities that are needed by Btrfs users 41 | 42 | * **Compatibility:** 43 | This should not break any compatibility for those not using Btrfs. 44 | 45 | If it gets to the point where the Stream kernel sources can no longer support Btrfs (see below), a separate kernel can be used for those that need Btrfs support, rather than risking compatibility for non-Btrfs users 46 | 47 | ## Drawbacks 48 | 49 | ### Kernel diverging from upstream 50 | Concern: Right now the EL10 kernel has not deviated much from upstream - later on in the lifecycle it might get more and more backports of separate subsystems, and keeping a feature enabled that Red Hat does not test for in the Stream kernel might get harder 51 | 52 | Mitigation: When that happens AlmaLinux might need to ship the Hyperscale kernel (which closely tracks the Fedora configuration) rebuilt for AL. Wearing my Hyperscale hat we can work with the Alma kernel team to make sure the kernel modules that Alma needs are enabled in our kernel config 53 | 54 | ## Benefit to AlmaLinux 55 | 56 | Combined with other recent features enabled in AlmaLinux (frame pointers, x86-64-v2 rebuild), this will strengthen AlmaLinux's reputation as an Enterprise Linux distribution where it is possible to innovate. It will also help organizations that use Btrfs more easily onboard Alma. 57 | 58 | ## Scope 59 | 60 | * **Proposal Owners:** 61 | 62 | * Send PRs to enable Btrfs, e.g. for the following packages 63 | * anaconda 64 | * bcc 65 | * buildah 66 | * cockpit 67 | * ignition 68 | * kernel 69 | * libblockdev 70 | * libguestfs 71 | * osbuild 72 | * osbuild-composer 73 | * podman 74 | * pykickstart 75 | * python-blivet 76 | * skopeo 77 | * udisks2 78 | * virt-v2v 79 | 80 | * Request that Core SIG adds needed packages be pulled into the distribution e.g. 81 | * btrfs-progs 82 | * compsize 83 | 84 | * **Other Developers:** 85 | * review and merge PRs 86 | * import needed new packages, likely from Fedora 87 | 88 | * **Policies and guidelines:** N/A 89 | * **Trademark approval:** N/A 90 | 91 | ## Unresolved Questions 92 | 93 | * ~~Are all the dependencies to Btrfs enabled already in the EL kernel?~~ Yes. 94 | * ~~If not, is the extra deviation and implications of that acceptable?~~ N/A 95 | 96 | 97 | ## Acknowledgments 98 | 99 | 100 | 101 | -------------------------------------------------------------------------------- /rfcs/0006-enable-crb-on-almalinux-10.md: -------------------------------------------------------------------------------- 1 | # RFC: Enable CRB by default for AlmaLinux 10+ 2 | 3 | * **RFC Number:** `0006` 4 | * **Author(s):** [Neal Gompa](ngompa@almalinux.org) 5 | * **Status:** Accepted 6 | * **Created:** [2025-05-13 13:45 UTC] 7 | * **Updated:** [2025-05-29 23:00 UTC] 8 | 9 | ## Abstract 10 | 11 | Enable the CRB repository by default on AlmaLinux 10 onward. 12 | 13 | ## Motivation 14 | 15 | * **Problem Statement:** The full content set is not available by default, which is a problem when people enable EPEL, as it requires the CRB repository. This results in issues as people complain when they enable EPEL that packages are broken when they are not. 16 | * **Goals:** Reduce user confusion and support burden with using common third-party repositories that leverage CRB content at runtime. 17 | 18 | ## Detailed Design 19 | 20 | * **Proposal Details:** The CRB repository will be changed from disabled-by-default to enabled-by-default. 21 | * **Implementation Plan:** Update the `almalinux-crb.repo` file in `almalinux-release` to enable the CRB repo. 22 | * **Compatibility:** No negative impact, it's purely additive. 23 | 24 | ## Drawbacks 25 | 26 | One more repository is loaded by default, which slightly slows down metadata download on constrained systems. 27 | 28 | ## Benefit to AlmaLinux 29 | 30 | This ensures the complete content set is offered and avoids issues with third party repositories that depend on CRB content. 31 | Notably, Fedora Extra Packages for Enterprise Linux (EPEL) requires CRB and users regularly forget to turn it on and have dependency issues. 32 | With EPEL 10, `epel-release` will grow a conditional dependency on `selinux-policy-extra` that is [shipped in CRB](https://gitlab.com/redhat/centos-stream/rpms/selinux-policy/-/merge_requests/199), 33 | and if the repository is not enabled when `epel-release` is installed, the dependency will never be evaluated due to how DNF works for conditional weak dependencies. 34 | Enabling CRB by default makes things smoother and easier for users, and we do not have to burden ourselves with dealing with users trying to figure out inscrutable 35 | errors in the default configuration. 36 | 37 | ## Scope 38 | 39 | * **Proposal Owners:** Pull request to `almalinux-release` to enable CRB on a10/a10s 40 | * **Other Developers:** N/A 41 | * **Policies and guidelines:** N/A 42 | * **Trademark approval:** N/A 43 | 44 | ## Unresolved Questions 45 | 46 | N/A. 47 | 48 | ## Acknowledgments 49 | 50 | N/A. 51 | --------------------------------------------------------------------------------