About 10 to 14 days before estimated Fedora release

• open freeze: tell packagers to only build packages if there is a strong reason to
• check more aggressively for broken deps and broken packages to make sure they get fixed

When final fedora-release got built and published

• Add aliases to mirrormanager; once done
  • build final rpmfusion-{non,}free packages to for release in question where the release and updates repo are enabled, but development disabled; generate a new rawhide key and include it as well;
  • adjust rpmfusion-{non,}free-remix-kickstarts to use proper mirror manager urls
• Prepare a "RPM Fusion is ready for F X" announcement mail

When Fedora release is finished

• remove all packages that are known to be broken
• remove all packages that have broken deps
• remove all *-kmod-src.rpm packages from the repos; at the same time rebuilt all kmod packages and make sure akmods packages get built
• mkdir releases/X; cp development/X/Everything
• create empty updates{,-testing} repos

branching

First bunch

Something like 0 to 14 days before release branch cvs:

• add line for new release in CVS at {non,}free/common/branches (leave the devel entry as it is)
• create and add new mock config files to all builders; let them use rawhide (as the directories for the new release is not there yet) temporary as there are no updates repos yet
• create amnd add target files for plague-builders and restart them; then create and add target files for plague-server and restart them
• some more steps on the CVS box that only Xavier knows
• Branch in CVS:

for j in free nonfree; do for i in /cvs/${j}/rpms/*/devel/*.spec,v ; do packagename=$(basename $(dirname $(dirname ${i}))); if [[ -e /cvs/${j}/rpms/"${packagename}"/dead.package ]]; then echo "${packagename} seems to be a dead.package, but contains a spec file" >&2; else echo /usr/local/bin/mkbranchwrapper-${j} ${packagename} F-12; fi ;read -t 2 -s -n 1 ; done; done &> log

• adjust config files for push scripts and test the scripts
  • To make sure the push scripts know about the "old" packages:

There would be a work-around when populating the release repo
for the first time. Copy "development" to F11 updates, run
WhatsNew.py for that repo, then move the packages to F11 release.

Second part

When new release is out and rawhide is rolling towards the next release again:

• finally adjust the dist release in CVS at {non,}free/common/branches
• adjust dist tag and release version in mock config files of all builders
• adjust config files for new release to point to new directories instead of rawhide
• build a new release rpm that has rpmfusion-rawhide enabled and stock repos disabled
• add taret for new release in bugzilla