Release Process

This section covers program management information related to the process of getting a release out the door. The document is in chronological order, referencing various SOPs, with small steps directly in-line, and notes below.

You may choose to create a wiki page to track the status of housekeeping tasks, as has been done historically.

Workflow

Rebase warning mail

This is the email that should be sent out 1-3 weeks before the Branch point. The actual rebase is covered in the Branching SOP.

Greetings,

This e-mail is intended to inform you about the upcoming Bugzilla changes
happening on TKTK (Rawhide bug rebase) and what you need to do, if anything.

We will be automatically changing the version for most rawhide bugs to Fedora TKTK.
This will result in regular bugs reported against rawhide during the Fedora TKTK
development cycle being changed to version 'TKTK' instead of their current
assignment, ‘rawhide’.  This is to align with the branching of Fedora TKTK from
rawhide and to more accurately tell where in the lineage of releases the bug was
last reported.

Note that this procedure does not apply to bugs that are open for the ‘Package
Review’ or 'kernel' components or bugs that have the ''FutureFeature'' or ''Tracking'' keywords
set. These will stay open as rawhide bugs indefinitely.

If you do not want your bugs changed to version ‘TKTK‘, add the ''FutureFeature''
keyword. If you need help changing a large amount of bugs manually, we’d be glad
to help.

The process was re-approved by FESCo https://pagure.io/fesco/issue/1096 .

Bug rebase notes

Bugs that meet all of the following conditions are branched from Rawhide to the newly-created version:

  • product == "Fedora" or "Fedora Container Images"

  • version == rawhide

  • component != "Package Review"

  • component != "Container Review"

  • component != "kernel"

  • component != "Changes Tracking"

  • keyword ''FutureFeature'' is '''not''' present

  • keyword ''Tracking'' is '''not''' present

  • the string ''RFE'' is '''not''' present in the summary

  • status != CLOSED

According to jforbes, the reason we exclude kernel bugs is two-fold: 1. A number of reported kernel bugs are longer-term issues that need to be solved over time, or bugs which upstream has to eventually get to. It has become the place to file these bugs, even if not against the rawhide kernel in specific so that they do not get auto closed in a year. 2. Rawhide kernels are most typically built as debug kernels only, and many bugs filed against them are not reproducible on branched non-debug kernels.

Go/No-Go Meeting notes

The meeting script in the Go/No-Go SOP provides a general framework for running the Go/No-Go meeting. The general flow is to verify that a compose is available, review blocker bugs, check that the test matrices are completed, and that CoreOS and IoT are ready.

The compose section is generally very quick. Release Engineering or QA will confirm that a candidate compose exists. If there is no candidate compose, skip straight to a "no-go" decision.

If there are proposed or accepted blocker bugs, the meeting becomes a blocker review meeting to evaluate them. This portion of the meeting can be led by a member of the QA team or by the Program Manager. It is not uncommon to defer some bugs until later in the meeting so that last-minute testing can be performed.

In the test matrices section, QA will review the results of tests. Some optional tests may not be complete.

Finally, the Program Manager polls each of the constituent teams. If they all vote "go", then the release is "go" and will be released on the coming Tuesday. The Program Manager’s work is done (at least as far as this goes). If the release is "no-go", then a follow-up meeting must happen.

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