Changes (Deferring) SOP

This document describes the process of deferring Changes to the next release.

Timing/trigger

This process is triggered by FESCo or the owner deciding to defer a change. Often, this is the result of missing a contingency deadline or completion milestone. Unless the Change changes significantly, it does not need to go through the process again. Chnages can be deferred indefinitely.

Process

  1. Reply to the mailing list thread, only if the proposal has not yet been submitted to FESCo.

  2. Update the Milestone in the FESCo ticket, only if the ticket is still open (in other words, if FESCo has not yet reached a decision).

  3. Update the Change’s wiki page. Change the "Targeted Release" to the new release. Change the category to "ChangeAcceptedF<N>".

  4. Update the tracking bug. Update the Blocks field with the new release’s Change tracking bug. If the Change is deferred after bugs have been branched, reset the version to "rawhide".

  5. Update the Release Notes issue. Set the Milestone field to the new target release.

  6. Re-run the Change processing scripts for the old and new target release. See the instructions.

If the Change was previously approved, do not award the badge for the re-targeted release.

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