Babar logo
Workbook HEPIC Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Wkbk. Search
Wkbk. Sitemap
Logging In
Info Resources
Software Infrastructure
CM2 Introduction
Event Store
Modifying Code
Writing and Editing
Framework II
Find Data
Batch Processing
Advanced Infrastructure
New Releases
Main Packages
Event Displays
Contributing Software
Advanced Topics
Make CM2 Ntuples
New Packages
New Packages 2
Persistent Classes
Site Installation
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)

Workbook for BaBar Offline Users - New Packages: Getting your package into CVS

Putting your new code into an official BaBar release


Getting Started Writing a New Package

See the Workbook page New Packages: Making a new Analysis package based on BetaMiniUser to get started making your own analysis package to run in the BaBar framework. Once you have created this package, and are ready for your package to be included in the BaBar CVS repository and in future BaBar releases, follow the steps in this workbook chapter to get your new package included in the BaBar framework.

Initiating a New Package

Now that you have a working package, you may want to share it with others, test it in a newer release, have others work on the package with you, or just have some safe copies so that you can abort changes that go horribly wrong. Yourself and other users will quickly get bored having to check out and update PackageList by hand, and BaBar CVS provides an elegant solution to all the requirements just listed.

Test carefully
The first step is test your package carefully. You must test the package on both Linux and Sun operating systems (for example, noric and tersk machines), and verify that it compiles and that you have set up your link_ and bin_ files appropriately (see the workbook section New Packages I for instructions on how to use the SoftRelTools script to do this). The reason you must test your code on these different platforms is that the compilers are different and will react differently to coding errors - the Sun compiler generally being more fussy. If your code deals with online matters (which is not the case for analysis releases), it must also be tested on one of the online machines.

If you fail to test your code carefully and commit code with bugs, you will cause crashes in the nightly compilations of BaBar code and will receive automated emails instructing you to fix your package.

Request the creation of a new package
The next step is to "request the creation of a new package". In this step you request that a new package is initialized, and once this is done you can import your new package files into that package and have it included in the BaBar Software Release Structure.

To request the creation of a new package, you fill out the Package Request form, and wait for a reply from a Software Release Coordinator.

Put your new code into the new package
Once you receive an email from the Software Release Coordinator, you can check out the shell of your new package (a directory with just a GNUmakefile), copy in the files you have developed, and commit your changes to CVS. Full instructions for Importing files into a New Package are found by following this link.

Telling the BaBar framework about your new package

The PackageList package also needs to be updated to tell the BaBar framework about your new package. Previously you did this in a private version of PackageList that you checked out into your test release. Now you need to update the HEAD of PackageList and commit those changes. The steps to follow are:
  1. Contact the Package Coordinator for the PackageList package and ask for permission to update the file PackageList/ with information about your new package. Once they have replied giving you permission to update their package, do the next steps:
  2. addpkg PackageList HEAD
    - you MUST use the HEAD of the PackageList package, as using older versions (e.g. the version that comes with analysis-26) and then committing changes back to the CVS repository can undo a lot of other people's work
  3. Edit into the changes identifying your new package as in the WorkBook chapter New Packages: Making a new Analysis package based on BetaMiniUser
  4. Then commit the file back to CVS: cvs commit PackageList/ (Only do this step once you have permission from the PackageList package coordinator.)
Now the HEAD of PackageList knows about your new package, and in future, rather than modifying PackageList/ by hand each time you check out your package in a new test release, you need only check out the HEAD of PackageList. After some time, the version of PackageList which contains your additions will become part of a release, and you will no longer have to check out the HEAD version. However, due to the structure of PackageList, you will generally have no problems if you do use the HEAD of this package.

Related documents:

Getting your new package included in a BaBar software release

To get your new package included in the next BaBar software release, you have to fill in the Checklist form.

Role and Duties of the Package Coordinator

Once you have added your new package to the BaBar software release structure, you (or someone else nominated at the time the request for a new package form is filled in) are responsible for that package, and are the coordinator for that package. You should subscribe to the Package Coordinator Hypernews group.

The package coordinator is responsible to ensure that code that goes into nightly release build will compile on all appropriate platforms, as well as for requesting for specific tags of packages to go into "official" builds. While other contributors might commit code which will appear in the nightlies, it is ultimately the responsibility of the package coordinator(s) to ensure that the BaBar code is not broken by a careless coding error.

The package coordinator should also ensure that contributors to the package are working on different areas of the code and that they commit their changes often to ensure that no difficult and time-wasting conflicts are generated.

Whenever code is committed to the CVS repository or a state of a package is tagged, the Software Release Tools automatically send an email out to the Package Coordinator with either the cvs log file or the announcement of the new tag.

Related links

Conforming to the SRT way of doing things.

Related Documents:

Managing an Existing Package using CVS

See the workbook section SRT and CVS Background for Software Contributors for instructions on maintaining and updating an existing package using CVS.

To get a package removed from a release, fill in the Package Removal checklist form.

When you have updated your release and commited the changes, you fill in the Checklist form that you used to announce the original creation of your package.

For information on facts such as:

  • Controlling which version of a package is used in a release,
  • Checking which version is scheduled for use in a release,
  • Checking to see what other packages are scheduled for the next build/release
read the BaBar Software Releases FAQ.

Reporting a bug-fix in a package

A BaBar software package consists of a cvs module for revision control, a package directory in $BFROOT/dist/packages, a Remedy problem tracking group, and one or more package coordinators. This section describes how to announce when a reported problem with a package has been solved.

To 'close a ticket' ie. if a problem with a package has been solved, by you or someone else, you can register this fix on the web. To do this, go to /BFROOT/ and

  1. Go to Computing->Tools->Remedy
  2. Click on "Display" (a specific problem report), after entering the problem number (without the zeros at the front)
  3. The problem report comes up, click 'modify', which brings up the modify page
  4. You can then close the problem with a comment on the solution

General Related Documents:

Back to Workbook Front Page

Doug Johnson
Joseph Perl
Jenny Williams

Last modification: 18 July 2005
Last significant update: 29 April 2003