Description
At each alpha freeze we branch the pending release away from devel/ which allows rawhide to move on while the pending release goes into bugfix and polish mode.
Action
PackageDB
Mass branching in the pkgdb is the first step. It should be done near the time that the scm branches are created so as not to confuse packagers. However, it does not cause an outage so it should be done ahead of time.
First, someone needs to add the new release to the PackageDB. See this section
Then a scmadmin needs to either start the mass branching process from the command line or by pushing a button on a web page. The web page method is to browse to https://admin.fedoraproject.org/pkgdb/collections/ login, and then click the "Branch All" button.
The command line method is to run:
pkgdb-client mass-branch -b F-13
Whichever method you choose, the command will start the mass branch process on the server and then return with a message that the branching is in progress.
When the branching is finished, you will receive an email that tells you of any unbranched packages as well as all the packages that were branched.
If something fails spectacularly, it is safe to try mass branching again at a later time. If only a few cleanups a re needed it might be better to do that with the regular branch commands.
Puppet
A couple files under puppet management need to be updated to be aware of a new branch.
pkgdb2branch.py
This file is used by an scmadmin to read data from pkgdb and create branches in the source control. Two parts need to be updated, one part that defines valid branches and what existing branch to create them from, and the other part defines a mapping of branch names in pkgdb to branch names in scm.
On the puppet server in a clone edit the modules/gitolite/files/distgit/pkgdb2branch.py file:
diff --git a/modules/gitolite/files/distgit/pkgdb2branch.py b/modules/gitolite/file index ce79467..c40e83c 100755 --- a/modules/gitolite/files/distgit/pkgdb2branch.py +++ b/modules/gitolite/files/distgit/pkgdb2branch.py @@ -29,14 +29,15 @@ BRANCHES = {'el4': 'master', 'el5': 'master', 'el6': 'f12', 'f11': 'master', 'f12': 'master', 'f13': 'master', - 'f14': 'master'} + 'f14': 'master', + 'f15': 'master'} # The branch names we get out of pkgdb have to be translated to git GITBRANCHES = {'EL-4': 'el4', 'EL-5': 'el5', 'EL-6': 'el6', 'OLPC-2': 'olpc2', 'FC-6': 'fc6', 'F-7': 'f7', 'F-8': 'f8', 'F-9': 'f9', 'F-10': 'f10', 'OLPC-3': 'olpc3', 'F-11': 'f11', 'F-12': 'f12', 'F-13': 'f13', 'f14': 'f14', - 'devel': 'master'} + 'f15': 'f15', 'devel': 'master'}
genacls.pkgdb
The other file is ran by cron that will read data out of pkgdb and construct an ACL config file for our scm. It has a section that lists active branches to deal with as pkgdb will provide data for all branches.
Again on the puppet server in a clone: modules/gitolite/files/distgit/genacls.pkgdb
diff --git a/modules/gitolite/files/distgit/genacls.pkgdb b/modules/gitolite/files/ index e531dc2..07b2ba7 100755 --- a/modules/gitolite/files/distgit/genacls.pkgdb +++ b/modules/gitolite/files/distgit/genacls.pkgdb @@ -22,7 +22,7 @@ if __name__ == '__main__': ACTIVE = {'OLPC-2': 'olpc2/', 'OLPC-3': 'olpc3/', 'EL-4': 'el4/', 'EL-5': 'el5/', 'EL-6': 'el6/', 'F-11': 'f11/', 'F-12': 'f12/', 'F-13': 'f13/', 'f14': 'f14/', - 'devel': 'master'} + 'f15': 'f15/', 'devel': 'master'} # Create a "regex"ish list 0f the reserved branches
Push the changes
When done editing the files, commit and push them, then restart puppet on the scm server in order to get the new files in place.
SCM
The following work is performed on pkgs01
Make git branches
Run pkgdb2branch.py to branch the repos on the scm server. The --branch-for option was designed with this use case in mind::
./pkgdb2branch.py --branch-for=f15
If for some reason that doesn't work, you can try this alternative:
cat pkglist.txt|./pkgdb2branch.py -c -
where pkglist.txt is a list of all the packages to branch.
Update ACLs
Although cron may have run, it is smart to manually run the cron job to make sure new ACLs are in place:
$ sudo -u jkeating /usr/local/bin/genacls.sh
Update preupgrade releases.txt
File a ticket with Infrastructure to modify the mirrors/releases.txt file to include pointers to the new release, for use by preupgrade.
Update AutoQA repoinfo.conf
The AutoQA project maintains a config file (repoinfo.conf
) that describes available package repositories and their inheritance. In order to have automated testing of Branched package builds, the repoinfo.conf
file needs to be updated. Please file an autoqa ticket to modify the repoinfo.conf
file to include pointers to the new release.
Koji
The koji build system needs to have some tag/target work done to handle builds from the new branch and to update where builds from master go. FIXME link to koji new target SOP
Fedora Release
The Fedora release package needs to be updated in both the new branch and in master. FIXME Link to fedora release bump SOP
Bodhi
Bodhi needs to be turned on for the new branch. FIXME Link to bodhi SOP
Enable nightly branched compose
A cron job needs to be modified and turned on for the new branch. FIXME Link to nightly branched SOP
Comps
A new comps file needs to be created for the next fedora release (the one after what we just branched for). FIXME Link to comps SOP
Mock
Mock needs to be updated to have configs for the new branch. This should actually be done and pushed just before the branch event. FIXME Link to mock update SOP
MirrorManager
Mirror manager will have to be updated so that the yum repo redirections are going to the right places. FIXME Link to MM SOP
Consider Before Running
- FIXME
- Produce an updated mock package ~1 week before mass branching, with a push to stable day-and-date with the branch availability. Should this be added to the rel-eng task schedule? --pfrields 15:20, 3 March 2010 (UTC)
- Make sure preupgrade knows about the new branch (not sure what exactly is involved with that). Should this be added here, too ? --mclasen 15:34, 3 March 2010 (UTC)