Edit Info Other
Login

PrepareRelease"

Differences between revisions 12 and 18 (spanning 6 versions)
Revision 12 as of 2009-05-26 18:05:49
Size: 2055
Comment:
Revision 18 as of 2009-11-15 12:14:03
Size: 2924
Comment:
Deletions are marked like this. Additions are marked like this.
Line 12: Line 12:
  * build final rpmfusion-{non,}free packages to for release in question where the release and updates repo are enabled, but development disabled   * 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;
Line 34: Line 34:
Something like 0 to 14 days before release Something like 0 to 14 days before release branch cvs:
Line 38: Line 38:
 * add target files for plague-server and plague-builders  * 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
Line 40: Line 40:
 * 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
Line 44: Line 46:
for j in free nonfree; do for i in /cvs/${j}/rpms/*/devel/*.spec,v ; do echo /usr/local/bin/mkbranchwrapper-${j} $(basename $(dirname $(dirname ${i}))) F-10; read -t 1 -s -n 1 ; done; done 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.
Line 56: Line 67:

 * build a new release rpm that has rpmfusion-rawhide enabled and stock repos disabled

 * add taret for new release in bugzilla

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

Infrastructure/PrepareRelease (last edited 2024-04-20 17:21:05 by Sérgio Basto)