Present: Dan, Heather, Ian, Joanne, Karl, Leon, Toby, Traudl
Release Manager: (Karl) So far this has been a re-engineering of the scripts Thomas wrote. Remaining questions, if any, have chiefly to do with policy: when should the Release Manager run? Where should output go? How to specify unit tests to be run? ...and so forth. For a complete report see Karl's page on the subject.
Data Manager: (Karl) Currently the Data Manager consists of Perl scripts which run MC jobs. Ultimately the output will go into the (Oracle) database; the design is being finalized now. For a preview, follow the "here" link on Karl's Data Manager page. Karen would like to hear your comments. For now (unless someone comes up with a good reason to do otherwise) the plan is for the Data Manager to first convert raw data files to ROOT by invoking ROOTWriter, then extract information to be saved in the database from the ROOT files.
Karl will put all relevant script files, etc., for both the Data Manager and the Release Manager into CVS presently.
TBIOROOT: (Ian) Cuttings from TBIOROOT have successfully grown into the two new packages, cal2Root and tkr2Root. For details see Ian's paragraph in this week's Core status page and follow the "original plan" link.
Do we need an acd2Root also? For testbeam data we don't, and we're hoping to start fresh for balloon data, but we will have to have something in place for PDR. Fortunately, this should not entail a lot of work.
ROOT Persistency: Meanwhile we ought to keep an eye on the ATLAS effort aimed at providing a real ROOT persistency service (unlike the hobbled one Gaudi now provides).
Core status: (Toby) See the Core status page for details. Some highlights:
a pointer to some real work (on trigger efficiencies) done by Steve Ritz using the new pdrApp/usrAlg
Heather's new ntuple package ntuplWriteSvc is up and running, and its requirements file provides an excellent example for other Gaudi service writers.
UW GLAST development server. This new facility is up and running. Let Toby know if you want an account. It should be extremely helpful in getting new users started in a known environment before moving to local machines. For some it might be the only development environment they need.
There was discussion of setting up something similar for SLAC unix. It should not be difficult since much of the functionality (e.g. common file system) has been there all along. What's needed at a minimum is a publicly-accessible collection of built packages and a convenient way to set up the individual user's environment, e.g., CMTPATH.
Java Gui Front-end for CMT: (Dan, Ian) Dan has been studying Toby's vcmt code; Ian has put together a Java gui look-alike but with no brains attached (yet). Once they have a better understanding of vcmt functionality and implementation, a complete Java version for unix should be forthcoming and much appreciated. It should be possible (and extremely desirable) to build it in such a way that it can later be gracefully extended to be used on Windows as well so we have only one such product to maintain.
J. Bogart Last Modified: 08/04/2004 15:41