This requires redhat-rpm-config changes for default payload compression,
as well as new RPM and XZ packages for koji builders. Bill Nottingham
and Dennis Gilmore are responsible for getting the packages built
for Koji. Bill Nottingham is responsible for getting the redhat-rpm-config
changes in place, which depend on the koji packages being live first.

Schedule

Given the changes required for the above features and the given
schedules, Release Engineering will be ready to start scripted rebuilds
on Thursday, July 23rd. All automated rebuilds should be finished prior to the Feature Freeze, which is July 28th.
Any clean-up manual rebuilds should be finished prior to the Alpha Freeze, which is August 4th.

Opting Out

Release Engineering has given maintainers the ability to
opt out of the scripted rebuild in order to do the build on their own.
Note that every single package needs to be rebuilt, regardless of the
contents.

In order to opt out of the scripted rebuild, a maintainer will need to
check a file into their package's devel/ branch, named noautobuild.
This file should contain a short rationale of why you wish to do the
build yourself.

If the build initiation script encounters such a file, it will skip that
package. However, given the tight deadlines (Feature freeze being the
28th of July, Alpha Freeze being the 4th of August), a very short grace period will be given for completing
the builds on your own. If your build has not been attempted by the
1st of August, the script will no longer honor the noautobuild request and
will attempt to rebuild your package. If, however, a rebuild has been
attempted, the script will bypass your module. This should prevent
multiple attempts to build something that fails for one reason or
another.

Scripts

Release Engineering has created two scripts. One is to initiate the builds, and the other is to query for items still needing to be built.

Build Initiation

Generate a list of all packages in dist-f12
Loop through each package:
Query if a build has already been attempted/completed since koji changes went live.
If so, move to next package
If not, check out CVS
Check for a noautobuild file
If so, move to next package
If not, rpmdev-bumpspec
cvs commit;tag
make (background) build
Move on to next package

Each step will have some error catching and logging so that people
can clean up the various failures for whatever reasons. The builds will
be background builds, which will allow other builds done to take higher
priority when a builder has a free slot. However maintainers should
take care when doing this so that the background build won't take
'latest' precedent when it finishes. Asking rel-eng to kill the
scripted build will typically be enough.

Build Tagging

Once the rebuild script has finished, another script will run to tag the builds into dist-f12. This script will check that a newer build hasn't been done or started in dist-f12 since the scripted rebuild was submitted. This will protect against the scripted rebuild overriding an even newer build done while the scripted rebuild was waiting in the background.

Status Query

Release Engineering has developed a script to query dist-f12
and report on packages that have yet to be rebuilt. Results of these
queries will be delivered to various places, yet to be determined,
broken down by maintainer for easier discovery of work needed.

Maintainer Actions

Maintainers that wish to do their own builds should read the Opting Out section.

Frequently Asked Questions

How do I opt out of the scripted rebuild?

When will my own build "count" for the rebuild?

After the updated redhat-rpm-config for XZ RPM Payloads is put into place, a build done by a maintainer will "count" toward the rebuild. The exact timing of this is not determined, but should likely happen after 0000 UTC Thursday the 23rd.

Will the rebuilds be ordered?

Currently there is no plan to logically order the rebuilds based on deps. The ordering will be alphanumerical based on package name. There are no planned ABI/soname changes that would require logical build ordering. Further, all the builds will be kept in a special tag (dist-f12-rebuild) until the whole run is done, and then they will be tagged into dist-f12 in one shot to minimize the shuffle of buildroot contents during the rebuilds.