Mass Branching SOP

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Add request to file AutoQA ticket to update repoinfo.conf with Branch information)
(https won't work when hitting bapp01 directly)
Line 31: Line 31:
pkgdb.url = "https://bapp01/pkgdb/"
pkgdb.url = "http://bapp01/pkgdb/"

Revision as of 18:09, 28 July 2010



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.



Mass branching in the pkgdb is the first step. It should be done near the time that the cvs 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 cvsadmin 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 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.

Warning (medium size).png
Target pkgdb-client against bapp01
At present there is a bug in the mass branching code so that the branching seems to work but the changes aren't saved in the database. I think this occurs when the server handles other requests while the packagedb is processing a mass branch. Performing the mass branch on bapp1 which is not handling other requests while the mass branch is occurring is one way to work around this. It's likely a bug in how forking in the mass branch code is interacting with the database connections.

Retarget pkgdb-client to use bapp1 by changing the value of pkgdb.url in either /etc/pkgdb-client.cfg or ~/.fedora/pkgdb-client.cfg.

pkgdb.url = "http://bapp01/pkgdb/"


The following work is performed on cvs01

Disable logins to cvs

  1. sudo crontab -u toshio -e
  2. Comment out the cron job
  3. CVSROOT=/cvs/pkgs cvs co CVSROOT
  4. cp CVSROOT/admin/avail CVSROOT/admin/avail.bak
  5. edit CVSROOT/admin/avail and comment out everything below the cvsadmins acl:
    unavail | | rpms
    avail | @cvsadmin | rpms
    ## Fedora SPARC team
    #avail | @fedora-sparc | rpms
    ## Fedora IA64 team
    #avail | @fedora-ia64 | rpms
    ## Fedora S390 team
    #avail | @fedora-s390 | rpms
    #avail | dwmw2,@provenpackager | rpms/0xFFFF
  6. cvs commit your changes

Disable logging

  1. CVSROOT=/cvs/pkgs cvs co CVSROOT
  2. edit CVSROOT/loginfo and comment out all of the lines
  3. <cvs commit the change to the repository

Create the branch directory

Similarly to /cvs/pkgs/devel, the branch directory /cvs/pkgs/F-13 will automatically be populated with symlinks to /cvs/pkgs/rpms/*/F-13. This should be automatically handled by the mkbranch script in CVSROOT/admin/mkbranch.

mkdir /cvs/pkgs/F-13
chmod g+w /cvs/pkgs/F-13

Make cvs branches

Run to put the files and directories on the cvs server. The --branch-for option was designed with this use case in mind::

./ --branch-for=F-13

If for some reason that doesn't work, you can try this alternative:

cat pkglist.txt|./ -c -

where pkglist.txt is a list of all the packages to branch.

Now turn everything back on.

Update branches file in common

The branches file in cvs/pkgs/common/branches dictates where builds go from cvs branches. This needs to be updated once the branching is done.

Regen ACLs

As a final step, refresh the acls file with all the new F-10 branches:

sudo -u toshio /usr/local/bin/

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.

Getting a List of Unbranched Packages

After mass branching you may want to run sanity checks to see if there were packages that weren't successfully branched. There's a script on the cvs server that can help you do this. The script needs to be run first on the cvs server and then on a machine with the kojiclient libraries installed (your local workstation should be fine.).

On cvs1:
CVSROOT=/pkgs/cvs cvs co CVSROOT
CVSROOT/admin/find-unbranched cvs F-12 > unbranched

On your workstation:
scp .
scp .
./find-unbranched compare F-12 unbranched

Notes on Optimization

  • If we could enhance the mail notification script for cvs to detect mass branching then we wouldn't need to close cvs during mass branching requests. (Currently, the rate for this is 3 pkgs/minute purely for the cvs portion (pkgdb information is cached at this point.))

Consider Before Running

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