Changes Process

Fedora’s Change Process is important to coordinate the development of the next Fedora release. We need to know about disrupting changes coming to the next release to set the scope of release, but it also helps as marketing tool even for leaf changes. For more details on Change Process, see the Changes Policy.


The Program Manager’s key responsibility is to maintain Changes Process — scheduling, submission, announcements, reporting and tracking. One of the main responsibilities is helping Change owners through the submission process. The Program Manager works on the Changes Policy with the Fedora Engineering Steering Committee (FESCo), Working Groups and other Fedora teams and bodies (documentation, marketing, etc.).


The SOP consists of two phases: Change submissions and Changes tracking.


Change submission is done in the Fedora Project Wiki.

  • Set up infrastructure for Changes on the Fedora Project Wiki (for a new release) — correct categories, ChangeSet page etc.

    • Create Category:ChangeAcceptedFXX, where XX is Fedora version

    • Create Releases/XX/ChangeSet page, where XX is Fedora version

  • Each change has to be proposed by Change Owner. Once Change category is set to ChangeReadyForWrangler, check formal correctness - all required fields are filled in, right category is set, page structure is correct (important, as scripts are used to parse the document).

    • If a proposal has missing, incomplete, or confusing information, set the category back to ChangePageIncomplete and email the change owner(s) to let them know what you’re looking for.

  • Once Change page is correct enough, it has to be announced on devel-announce and devel mailing lists.

    • Include the version, type (Self-Contained or System-Wide), and title in the email subject For example: F37 proposal: Switch to Darwin kernel (System-Wide Change Proposal)

    • Include the this is just a proposal boilerplate, wiki page URL, and content of the proposal in the email body

    • Set category to ChangeAnnounced

  • After 7 days, submit the Change proposal for FESCO’s approval. Create a FESCo ticket that includes

    • Version, type, and title in the ticket summary

    • Change summary in the body of the ticket

    • Link to change proposal in the body of the ticket

    • Link to devel-announce and devel threads in the body of the ticket

    • Tag owners in the body of the ticket

    • Pagure metadata:

      • "system wide change" or "self contained change" tag as appropriate

      • "Fedora <N>" milestone

  • After FESCo meeting, process Changes queue:

    • if Change is approved

      • Remove the {{Change_Proposal_Banner}}

      • set category to ChangeAcceptedFXX, where XX is aimed version

      • create Tracking bug (see tracking section)

      • award the Change Accepted badge

    • if Change is denied, set category to ChangePageIncomplete

    • if FESCo asks for clarification or more details, work with Change owner on updates

Submitting to both mailing lists at the same time will give the threads identical URLs (modulo the list name) in Hyperkitty, which makes adding links to the FESCo ticket easier.


Create tracking bug

After a change is accepted, you can use the scripts in the pgm_scripts repo to create Bugzilla bugs.

  1. Run make version=<version> type=<type> build to pull the contents of change proposals

  2. Run make bz to create Bugzilla tracking bugs

  3. Edit each bug to:

    • Correct the assignee to the change owner and ensure the CC entries are correct

    • Set the status to ASSIGNED

    • Set the bug as a blocker of that release’s tracker bug

  4. Add the Bugzilla URL to the wiki page in the Current Status section

  5. Create an issue in the Release Notes tracker and add that URL to the wiki page in the Current Status section

The Bugzilla script isn’t very smart. If you re-run it (e.g. to correct an email address), it will create duplicate bugs for any changes it already processed. Edit the feature-pages.csv file to remove already-processed bugs or run make clean and re-run steps 1 and 2 above.
The Bugzilla API will reject email addresses that don’t exist in Bugzilla. If issue creation fails, that’s probably the cause.

ChangeSet wiki page

Each release has a ChangeSet page (Releases/N/ChangeSet) in the wiki that lists the accepted changes for that release. Step 1 above produces a file called ChangesList that includes the Mediawiki-formatted content you can copy and paste into the appropriate section of the ChangeSet wiki page.

Re-run the make …​ build script and update the wiki page after finishing the steps in the Create tracking bug section and regularly as code completion deadlines approach. This ensures that the page is up-to-date.
James Mills (jamills) from Red Hat’s Product Experience team uses the ChangeSet wiki pages to prepare for upcoming RHEL releases. If you change how or where this information is published, please give him a heads up.

Update status

Changes progress is tracked in the Change bugs. It’s important to know the status especially of System-Wide changes to trigger Contingency plan in case of need.

It’s good to take a look on Changes progress periodically and update the ChangeSet page with step 1 in the tracking bug creation process.

Two weeks before each completion milestone, announce it on the devel-announce mailing list and ask Change Owners to report Change status and potential issues. Work with Change Owners during this two weeks to collect status for FESCo. Use mass bug comment feature of Bugzilla.

The day after the deadline, open a FESCo ticket with Changes that did not meet required status. See FESCo #2218 for an example.

We don’t have a good way of tracking the contingency deadline for Changes with a contingency plan. This essentially means we trust Change owners to self-enforce. If you want to make life better, come up with a better solution.

Deferring Changes

If an approved Change is not completed in time for the release, it is automatically deferred to the next release. It does not need to go through the approval process again. To defer a Change:

  • Update the Release: field and the ChangeAcceptedFXX category on the wiki page

  • Change the tracking bug to the rawhide version and set it to block the appropriate meta bug.

  • Edit the Release Notes issue to reflect the new version