Release Process

This section covers program management information related to the process of getting a release out the door. The table of contents below is organized by category. The document beyond that is in chronological order.

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

Wiki and website creation

There are so many places in the wiki to create things. This is probably not an exhaustive list. Hopefully in the future we’ll have improved this process by consolidating and automating.

  • Update the index.html page on the web view of the schedule.

  • Create a release page (Releases/N) in the wiki that collects the pages in that category. You can use {{Special:PrefixIndex/Releases/N/}} to make it automagic (replacing "N" with the release number). This is a good target for de-wikifying.

  • Create a release schedule page (Releases/N/Schedule) in the wiki. For Fedora 31 and previous, this included a manually-transcribed copy of key milestones. For Fedora 32 and beyond, Ben decided that’s a good way to introduce human error and made that page point to the web view of the schedule instead.

  • Create a ChangeSet page (Releases/N/ChangeSet) in the wiki. The output of the change processing scripts gives you the content for this page.

  • Create a Spins page (Releases/N/Spins) in the wiki. Copy this from the previous version and make any changes as appropriate. This is another good target for de-wikifying.

  • Create a Release blocking deliverables page (Releases/N/ReleaseBlocking) in the wiki. Again, copy this from the previous version and make changes as appropriate. Stop me if you’ve heard this before, but this is a good target for de-wikifying.

  • Add the new release to the Releases page (or really, the nav.adoc sidebar).

  • Add the new release to the Changes wiki page.

  • Create a tracker bug for the release in Bugzilla. This simplifies reporting and branching (particularly for Fedora N+2 proposals that come in before N+1 is branched)

    • Use the Changes Tracking component

    • Set the Alias to "F<N>Changes"

    • Add the Tracking keyword

Spins keepalive

Solutions (formerly Spins and Labs) are targeted showcases of Fedora Linux software. As such, we want to make sure they’re well-maintained. To that end, FESCo approved a process where the Program Manager checks with spin owners to make sure they’re still around and wanting to produce the spin. The deadline corresponds with the Self-Contained Change deadline.

The process is defined in the Spins keepalive SOP.

You can be flexible with the deadline, as RelEng does not need much lead time to stop making something.

Rawhide Rebase Warning

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 .

Branch day

Most of the branching activity is done by Release Engineering, but the FPgM handles the Bugzilla changes.

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.

The process is defined in the Branching SOP.

Release blocking deliverables

Some deliverables are release blockers — we do not ship the release if they are not successfully composed. FESCo approved a proposal to use a static list of release-blocking deliverables. Formerly, this was a manual audit process each release.

A week before the branch point, create the release-blocking page in the wiki (see the F31 page as an example). Email this to the devel mailing list. Any edits should have been included in Change proposals, but it’s a good opportunity to catch anything that got overlooked.

Go/No-Go meeting

Before each public release, FESCo, QA, and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting. The Program Manager is responsible for scheduling and leading this important meeting.

During the meeting

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 review blocker bugs, verify that a compose is available, and that the test matrices are completed. 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.

The compose section is generally very quick. Release Engineering or QA will confirm that a candidate compose exists.

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.

Release Day

See Release Day SOP.

EOL Closure reminder

The EOL closure reminder is posted to all bugs for Fedora N-2 after the GA date of a new release. See the EOL warning SOP for the process.

EOL day

See the EOL day SOP

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