Present: Toby, Thomas, Ian, Richard, Masanobu
Arache has run into the consequences of the modifications to reqs files to eliminate version numbers. He has glastsim and tbsim in the same filespace (ie same $CMTPATH), and CMT gets confused (recall that tbsim packages are v99). Thomas has verified in the new repository that the recursive checkouts now work.
We need to create a use case document on the web indicating where to checkout packages and how to manipulate the CMT path variables to allow co-existence of glastsim and tbsim (Thomas).
We went around the loop on this, finally agreeing that we should ask people to install Root in their ExtLib space (not separately). We would include it in our distribution tarball, so we control the recommended version. EXTLIB's reqs file identifies where to find it. We thought to provide a HowTo for modifying EXTLIB to point to a non-standard location.
Toby has installed 2.25.03 on the SLAC NT V: disk.
It looks like we will continue using tbrecon for the balloon flight. It needs to follow the rest of the code to the SLAC repository. Toby has begun work on packaging it (in conjunction with Jose, but we assume Jose will not continue with that). Toby ran into a circular dependency and paused there. We decided to table the discussion, leaving tbrecon at Stanford, until Heather's return.
Joanne reported in absentia that she has the xml and instrument packages modified to use the xml parser. She is using the instrument test package to debug. No showstoppers yet.
Toby will packageize vcmt. [Ed. done: v6]
Test code will go in a test folder under src in the directory tree.
Toby has extracted the online component of RootWriter and built it for NT.
Toby made a minor mod to CLHEP's reqs file to turn off its min/max templates. He will tag this with a patch ('p') version increment: v1r5p1. There is a problem with this, however. If a package requests v1r5, and CMT does not find it, it fails, even though it would use v1r5p1.
Toby mentioned a concern Joanne brought up about shared code development. I talked to her after the meeting. She is concerned that one doesn't know if someone else is modifying code in any given package. cvs doesn't help with this. If this is deemed a problem, we could consider adapting something like Masanobu's front end to cmt checkout (called getpack) to keep track of packages being checked out, and could add a front end to commit to indicate packages open/closed for development. We also still have to list of package owners. On the other hand, we are a small group with reasonably fine segmentation of the code, so such overlaps may not happen too often. We can discuss this in future.
Last Modified: 06/01/2010 15:45