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 <email@example.com> 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:
Set up the production version you want to patch
setup D0RunII <production-version> setup D0RunII p17.00.00Make a new test directory
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:
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
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 d0recoLook to see what you changed
cvs -n -q updateCommit the changes to CVS just like you would in a test version
cvs commit -m"meaningful-comment"Tag your changes with your own personal tag (here <p17-br-01>).
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 d0recoChose an appropriate tag name and rtag the package.
cvs rtag -r <branch-name> <your-tag> <pkgname> cvs rtag -r p17-br p17-br-01 d0recoDon't forget to update the version of your tag next time.
Request a "normal" release using the D0 Release Request System. Do not request a bug fix release.
Be sure to specify:
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.