Patching a production version of D0 code

Production releases are always done from a branch. For example all versions of p17.xx.yy are on the branch p17-br. This branch exists in all packages used in the p17 releases. All corrections to any package that will go into a production pass release must be put onto the head of the appropriate production branch. This page describes a method for doing this.

NOTE: If your package wasn't in the test (t) release when the first version of the production release sequence was made, it will not have had a branch created. Please contact D0 Release Manager <d0-release-mgr@fnal.gov> and ask that the branch be created. We will need to know the previously rtaged version name where the branch should be placed, the package name and the production release.

You must not use this mechanism to introduce major code updates. Production pass releases must have only bug fixes unless specifically authorized by the production executable managers in consultation with the algorithms and/or physics coordinators. Even bug fixes must be passed by the appropriate executable manager before being applied to make sure that they should go in at this time. This will most likely mean that you have to apply the patch twice, once to the production release and once to the test release. That's life.

Step by step instructions, I've put production release p17.00.00, branch p17-br in as an example under the generic commands.

FIRST talk to the relevant executable manager to determine if your patch will be accepted. Currently the executable managers are:

• Qizhong Li - D0reco, RecoAnalyze and RecoCirt
• Avto Kharchilava - All physics event generators
• Thorsten Kuhl - All simulations except TrigSim
• Chris Potter - Trigsim Level 3
• Mikolaj Cwiok - Trigsim Level 1/Level 2
• Abaz Kryemadhi, Mikolaj Cwiok - Level 2
• Chris Potter - Level 3 Filters
• Gustaaf Brooijmans - L3 Daq (non-filter)
• Nobu Oshima - Examines (online parts only)

Set up the production version you want to patch

    setup D0RunII <production-version>
      setup D0RunII p17.00.00

    newrel -t <production-version> <test-directory>
      newrel -t p17.00.00 p17-branch

Go into that directory

    cd <test-directory>
      cd p17-branch

Tell SoftRelTools where the top of your area is and setup the RCP environment:

    d0setwa
      d0setwa

NOTE: whenever you change the area you are working, you need to repeat the d0setwa in the new area.

Get your package from the production branch. The second argument is mandatory or you are getting the test release (t01.xx.yy) series instead of the production release.

    addpkg <pkgname> <branch-name>
      addpkg d0reco p17-br

Modify stuff
gmake all
gmake test
run tests
modify
gmake all
gmake test
etc. etc.

Amazing how many people don't do this. If it doesn't compile and run on the data for which the bug was reported either fix it or try to locate the package that is actually causing the problem and request that it be fixed.

If you don't have a decent test (itest in particular), addpkg a package that uses your package and creates an executable. Use it to test your package. Do something other than "hope it'll work".

Go into the package directory

    cd <pkgname>
       cd d0reco

    cvs -n -q update

    cvs commit -m"meaningful-comment"

• Use a tag name starting with "v" for a test release only
• Normally use a tag name of the form -. i.e. p17-br-01 for a tag on the p17-br branch, the p17 production release branch.
• Always put the release name ("p17" for example) somewhere in your tag name to make it stand out in requests.
• Never use a tag name that can ever be used as a production release name, ie) of the form "pll-mm-nn" where l/m/n are digits

First check the tags that are already used (do not attempt to reuse a tag name. We aren't running out of numbers!)

    cvs history -Tan <pkgname>
      cvs history -Tan d0reco

    cvs rtag -r <branch-name> <your-tag> <pkgname>
      cvs rtag -r p17-br p17-br-01 d0reco

Request a "normal" release using the D0 Release Request System. Do not request a bug fix release.

Be sure to specify:

• your tag (which contains the production sequence name (p17)).
• that it be released in a particular production release (p17).
  (the box at the top of the request form that says "next test release". Change that. We sometimes have several production release sequences going on at once. So we need to know which one was patched.)
• Give a short description of the bug that's been fixed. "Bug Fix" is not a useful comment.

Now send a message to the appropriate executable manager, to your subsystem coordinator and to any other interested parties (such as the person who reported the bug) saying you have patched the production branch. Tell them which branch, the version number you've assigned, what you've done and any other information that might be helpful and necessary for them to test your changes.