Edit Info Other
Login

PrepareRelease"

Differences between revisions 4 and 12 (spanning 8 versions)
Revision 4 as of 2008-11-22 17:24:46
Size: 640
Comment: page was renamed from Admins/PrepareRelease
Revision 12 as of 2009-05-26 18:05:49
Size: 2055
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
= A 10 days before estimated Fedora release = = About 10 to 14 days before estimated Fedora release =
Line 6: Line 6:
= When final fedora-release is built and published =  * check more aggressively for broken deps and broken packages to make sure they get fixed
Line 8: Line 8:
 * 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 = 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

  * adjust rpmfusion-{non,}free-remix-kickstarts to use proper mirror manager urls

 * Prepare a "RPM Fusion is ready for F X" announcement mail
Line 14: Line 22:
 * remove all -kmod- packages from the repos  * remove all packages that have broken deps
Line 16: Line 24:
 * rebuilt all kmod packages and make sure akmods packages get built  * 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

 * add line for new release in CVS at {non,}free/common/branches (leave the devel entry as it is)

 * add target files for plague-server and plague-builders

 * 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

 * Branch in CVS:
{{{
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
}}}

== 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

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
    • 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

  • add line for new release in CVS at {non,}free/common/branches (leave the devel entry as it is)
  • add target files for plague-server and plague-builders
  • 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
  • Branch in CVS:

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

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

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