Documentation
- Doxygen not in real use; many packages with none or essentially none.
- fragmented user doc; latest packages list not up to date
- user doc not kept up to date in general
- Gaudi and CMT manuals not useful (enough) as user guides
- not even a block diagram of the sim/recon code
Release Management
- insufficient discussion of contents of a release prior to release. Identify all changed packages in a release and what's different.
- frequent releases - no real testing in place
Persistent Data Structure Definitions
- TDS/PDS versions not as similar as could be
- no clear conventions across the classes
- all stages of Root output need re-design (and perhaps TDS as well, per the first point)
- how does one know what is available on the TDS?
Code reviews
- do we need a real and formal review process?
CMT
- not stable yet? New versions require major updates to reqs files (v1r10 will do so yet again??)
- no vcmt on unix
- odd behaviour of (v)cmt in some cases, such as getting HEAD versions of dependent packages when checking out the HEAD of a package; not knowing when to update/rebuild which packages when external packages are changed.
Architecture
- no naming conventions; no way of navigating the dependency tree and which packages are in which shared library
- classes are defined in .cxx, .cpp, .h files. Multiple classes defined in a single file
- improper encapsulation of code into packages
System Complexity
- there are many components to the system: ssh, cvs, CMT, vcmt, xml, VC++ (or gnu IDE), G4/Gismo. Recon, Root, Gaudi. True expertise in these areas is not spread out enough in the group. Setup from scratch is a daunting process (note: this assumes a distributed computing model - users expect to be able to completely build the GLAST system on their desktop).
R.Dubois Last Modified: 11/10/2001 20:56