Mass Rebuild - SOP

Description

Periodically we do mass rebuilds of rawhide during the development cycle. This SOP will outline the steps necessary to do this.

Assumptions

This assumes that the mass rebuild has already been approved and scheduled via release engineering and FESCo. Coordinate with
infrastructure as well for any needed koji updates.

This also assumes that the mass rebuild does not need to be done in dependency order, and that the mass rebuild does not involve a ABI change.

Set up a web page for maintainers

First, describe the mass rebuild for maintainers; why it's being done, and how they can opt out. See the Fedora 12 example.

Update releng scripts

Release engineering scripts for mass rebuilds live in the releng git repository. You need
to edit the following scripts:

mass-rebuild.py

find-failures.py

mass-tag.py

need-rebuild.py

Change the following items:

- the build tag, holding tag, and target tag should be updated to reflect the Fedora release you're building for
- the 'epoch' tag should be updated to the point at which all features that the mass rebuild is for have landed in the build system.

Create the rebuild tag

The clone-tag command is a convenient command to use for creating th rebuild tag.

It not only creates the tag, but it will also copy over all package ownership info, package configs, and tag all the latest packages from the source. The end result of running this command is a functional up to date new tag that is a snapshot of the source tag in question. Running this command later will update the rebuild tag with any changes from the source tag.

For example, if we wanted to create a rebuild tag for Fedora 12 development we would issue:

koji clone-tag dist-f12 dist-f12-rebuild

We also want to prevent packages from manually tagging packages. To accomplish this we lock the tag with edit-tag: