Skip to main content
CentOS Stream Kernel Documentation
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  1. CentOS Stream Kernel Documentation
  2. /
  3. Docs
  4. /
  5. Subsystem Maintainer Expectations

Subsystem Maintainer Expectations

Overview

When a developer adds themselves as a maintainer or reviewer to a subsystem in the owners.yaml file (the modern, machine-readable successor to RHMAINTAINERS), they generally take on the ownership of decisions regarding that subsystem in the RHEL Kernel. Note: there are cases in which subsystems are minimally-maintained, and handle periodic security fixes, these should be continually monitored, with their workload evaluated by their respective PO.

Ultimately, If required_approval is set, the webhooks will strictly require your approval for changes touching your files.

This document outlines the responsibilities, expectations, and scope of being a subsystem maintainer for downstream RHEL and CentOS Stream kernels.

Core Responsibilities

1. Upstream Monitoring and Backports

  • Continuous Monitoring: Maintainers, through best effort, actively monitor the upstream Linux mainline for their subsystem, watching for important patches, API changes, and critical bug fixes.

  • Security & CVEs: With the continuous influx of kernel CVEs, maintainers are responsible for ensuring their subsystem meets Red Hat’s SLA (as defined by your PO or team lead) and compliance priorities for security fixes (also defined by your PO).

  • The Goalkeeper Principle: Maintainers, through best effort, enforce downstream integration quality. This means verifying that backports are complete, dependencies (Fixes:, Depends:) are met, commit ordering is correct, and cross-subsystem impacts are addressed.

  • kABI & Stability: Maintainers, through best effort, ensure changes adhere to the [https://one.redhat.com/rhel-development-guide/#con_product-stability_assembly_development]"Asimov Principle", protecting the kernel Application Binary Interface (kABI) and User-Space Interfaces (UAPI) from breaking within a minor RHEL release.

2. Bug and Issue Management

  • Point of Contact: Serve as the primary point of contact for customer bugs, support cases, and JIRAs filed against your subsystem.

  • Triage and Resolution: Investigate reported issues to determine if they are pre-existing upstream bugs or downstream-specific integration failures resulting from bad conflict resolutions.

3. Testing and Quality Assurance

  • Test Maintenance: Actively collaborate with your teams to address broken tests, triage failures, and resolve CI issues related to the subsystem.

  • Test Development: Actively collaborate with your teams to develop, curate, and maintain test suites to ensure ongoing functional stability and prevent regressions in downstream releases.

4. Configuration Management

  • Config Reviews: Every kernel configuration option (CONFIG_*) requires a maintainer to review and approve the decision to enable or disable a feature.

  • Upstream Defaults: The baseline default value should always align with the upstream default unless there is a strong downstream justification.

  • Maintaining Disabled Subsystems: If you are assigned to maintain an intentionally DISABLED subsystem, your primary responsibility is straightforward: reject config enablement changes and involve management if a request for enablement arises.

5. Derivatives and Rebuilds

The RHEL kernel serves as the base for several downstream kernel types:

  • Rebuilds — same RHEL source, built with a different buildroot or build options (e.g., kernel-automotive).

  • Derivatives — carry additional code or configuration on top of the base kernel. They either follow the RHEL process and schedule (e.g., RHiVOS) or operate on their own independent schedule and cadence (e.g., Red Hat Enterprise Linux for NVIDIA).

As a RHEL base maintainer, your responsibilities extend to the base kernel only:

  • Domain Expertise: Downstream teams are the subject matter experts for their platform-specific code. For example, automotive and FuSa (Functional Safety) engineers own automotive-domain code in a rebuild; downstream teams own their derivative-specific changes.

  • Change Ownership: When a downstream team applies customizations, additional patches, or enablements, a representative from that team must, through best effort, own and maintain those changes — including keeping them compatible with base kernel updates. In practice, this representative is usually the same person as the RHEL base maintainer for that subsystem.

  • Collaboration: Base maintainers should be available for consultation on subsystem-level questions from downstream teams, but are not expected to own, test, or maintain downstream-specific functionality.

6. Layered Products

  • Support Scope: As a RHEL Maintainer, you support the shipped code across all layered products as-is. Layered products consume the RHEL kernel without modifications.

Managing Commitments

  • Varying Workloads: It is understood that some subsystems are "lightly touched" and may only require attention once or twice a year.

  • Decommitting: Roles are not lifetime sentences. If the burden of maintaining a subsystem increases due to CVEs or architectural shifts, maintainers are allowed to decommit and step down from these roles.

  • Honesty in Expertise: "If you don’t know, you don’t know — and that’s okay." It is perfectly acceptable to acknowledge knowledge gaps and pull in other experts when necessary.

  • Escalation: Any questions or concerns should be always escalated to your manager and/or team lead.

gdoc_arrow_left_alt List of Subsystem Maintainers Commit Rules gdoc_arrow_right_alt