Changes (Processing) SoP

This document describes the process of processing Changes after FESCo’s vote.

Timing/trigger

Process Changes after the vote is final per FESCo’s ticket policy.

Process

Approved proposals

  1. Note the vote (e.g. "APPROVED (+6,0,-0)") in the comment, if not already recorded

  2. Apply the pending announcement label if the issue is still open. This lets the next meeting chair know to include an announcement of the decision in the agenda

  3. Edit the proposal’s wiki page

    1. Remove the {{Change_Proposal_Banner}} macro

    2. Replace the ChangeReadyForFesco category with ChangeAcceptedF<NN>

  4. Create new bugs with the scripts

    1. Run make version=<NN> type=<SystemWide|SelfContained> build to download and parse the wiki pages

    2. Run make bz to create tracking bugs in Bugzilla.

  5. Edit the created bug

    1. Add yourself to the cc field

    2. Set the bug to block the F<NN>Changes tracking bug

    3. Set the bug status to ASSIGNED

  6. When appropriate (see below), create a Release Notes issue with the Change template.

    1. Use Change: <title> as the issue title

    2. Replace URL HERE with the wiki URL

    3. Set the Milestone appropriately

  7. Add the Bugzilla and Release Notes links to the wiki page

  8. Update the Friday’s Fedora Facts entry

  9. Update the ChangeSet page

    1. In the scripts directory, run:

      1. make clean

      2. make version=<NN> type=<SystemWide|SelfContained> build to regenerate the content

      3. Copy the contents of ChangesList and paste into the appropriate section of the ChangeSet page

  10. If the Change involves a new Spin, add it to the Releases docs.

Bugzilla requires an email address to exist in the system in order to add it to a bug. If an email address listed on a wiki page does not exist in Bugzilla, that address will not be CCed on the bug. If no address listed exists in Bugzilla, the bug will remain assigned to the Change Wrangler. In that case you should try and find an address for a Change owner that does exist in Bugzilla and re-assign it, or ask the Change owner(s) to register in Bugzilla.
If the Change involves creating a new Spin, send the owners the Creating a Spin docs. Otherwise, the coordination with Websites et al will probably be overlooked.

RELEASE NOTES: most Changes should be considered for release notes, but sometimes this does not make sense. When a Change will not result in any notable impact on end users that can comprehensibly be explained to them, a release note is not necessary. An example of such a Change is https://fedoraproject.org/wiki/Changes/PortingToModernC : this is a highly technical Change that is only of consequence and interest to Fedora maintainers, not end users. When it does not make sense for a Change to have release notes, put "Release Notes tracker: N/A" in the "Current status" section of the Change page.

Rejected proposals

If a Change proposal is rejected by FESCo:

  1. Add {{Change_Rejected_Banner}} to the proposal’s wiki page below the title

  2. Update the wiki page category to Category:ChangePageIncomplete

  3. If a tracking bug was pre-created, close it with Status CLOSED → DEFERRED.

Want to help? Learn how to contribute to Fedora Docs ›