Workbook for BaBar Offline Users - New Packages: Getting your
package into CVS
Putting your new code into an official BaBar release
Contents
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.
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.
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:
- Contact the Package
Coordinator for the PackageList package and ask for permission to
update the file
PackageList/link_all_reco.mk with
information about your new package. Once they have replied giving you
permission to update their package, do the next steps:
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
- Edit into
link_all_reco.mk the changes identifying
your new package as in the WorkBook chapter New Packages: Making a new Analysis
package based on BetaMiniUser
- Then commit the file back to CVS:
cvs commit
PackageList/link_all_reco.mk (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/link_all_reco.mk 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:
To get your new package included in the next BaBar software release,
you have to fill in the Checklist
form.
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
Related Documents:
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.
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
- Go to Computing->Tools->Remedy
- Click on "Display" (a specific problem report), after
entering the problem number (without the zeros at the front)
- The problem report comes up, click 'modify', which brings up the
modify page
- You can then close the problem with a comment on the solution
General Related Documents:
Authors:
Doug Johnson
Joseph Perl
Jenny Williams
Last modification: 18 July 2005
Last significant update: 29 April 2003
|
