From FedoraProject

Jump to: navigation, search
Quick Links
If you know the process already, you can jump immediately to an empty Change Proposal form. Looking for help? Contact the Change Wrangler.


Fedora Release Planning Process

The motivation for the planning process is to raise the visibility of planned changes and make coordination and planning effort easier. Otherwise it is nearly impossible to follow all changes happening in a big project such as Fedora. It must be easy to submit the change proposal as early as possible, before the change is implemented and even in the very early state of the idea, to gather community feedback and review.

The list of accepted changes, or change set, is used by different teams across the project. For example, the change set may be used to prepare external facing materials like release notes and release announcements.

The planning process is an internal planning and tracking tool, and the final release is not required to reflect all proposed changes.

Change categories

Fedora Engineering and Steering Committee (FESCo) defined two Change categories:

  1. Self contained changes
  2. Complex system wide changes

Self contained changes

A self contained change is a change to isolated package(s), or a general change with limited scope and impact on the rest of distribution/project. Examples include addition of a group of leaf packages, or a coordinated effort within a SIG with limited impact outside the SIG's functional area. Self contained changes could be used for early idea state proposals for wider and complex changes.

Public announcement of a new self contained change promotes cooperation on the change, and extends its visibility. Change owners may find help from the community or useful comments. These changes don't have to be thoroughly reviewed by FESCo. Based on the community review, the self contained change can be updated to the complex system wide change category, and the owner may be asked to provide more details and extend the change proposal page.

Complex system wide changes

Complex system wide changes involve system-wide defaults, critical path components, or other changes that are not eligible as self contained changes.

Essential Communications

Fedora Packaging Committee

For changes that require modifications to the Fedora Packaging Guidelines:

  • The person or group proposing the Change is responsible for providing a first draft of packaging guideline changes to the FPC.
  • This draft does not need to be prepared prior to submitting the Change request, but must be complete by Alpha Freeze or the Contingency Plan will be invoked.

Release Engineering

For changes which require Release Engineering involvement:

  • Please work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook.
    • File a ​ticket with Release Engineering immediately when the change is accepted, with a detailed breakdown of changes needed.
  • Work must be substantially complete and in place by Alpha Freeze or the contingency plan will be invoked.

Trademark Approval

If your Change may require trademark approval (for example, if it is a new Spin), file a ticket requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process; if the request receives at least three positive votes and no negative votes within an approved period, it is considered approved.

For Change-related trademark approval, the Council has decided that 14 days is the normal time to reach consensus. This may be extended when it seems necessary to allow an adequate period for input.


For everyone

In general, Changes are for coordination of development effort and for communication (both internally and externally). They aren't mandates that someone else implement an idea (no matter how good that idea). If you have improvement in mind, work to get implementers committed to the effort before filing a Change, rather than expecting them to show up for work once the Change is accepted — that's simply unlikely to happen and the effort will likely fail, leading to sadness and disappointment all around.

For developers


Feel free to ask the Change_Wrangler for help.