Present: Joanne Bogart, Toby Burnett, Claudia Cecchi, Xin Chen, Richard Dubois, Heather Kelly, Michael Kuss, Sean Robinson, Alex Schlessinger, Tracy Usher, Karl Young
Gleam release: (Toby) See his Gleam notes (new features, to-do) for details. We're aiming for the end of this week. Current known show-stoppers are:
Persistence for AcdDigi; work on AcdRecon. Heather expects both to be done by Thursday AM.
Incorporation of sensible McParticle filter (Riccardo)
Resolution of checkout/build problems engendered by circular use statements.
Changes to TDS classes (for classes of public interest, at least, in particular certain CalRecon classes) to add const access methods where they don't already exist. [Note: as always, backward compatible changes - here adding a new method rather than changing the interface of an existing one in use - are preferred.]
TkrRecon work. 1) Get rid of recurrent non-fatal error message (preferably by fixing underlying problem). 2) Make pattern recognition class changes needed for consistency with other TkrRecon classes.
TDS classes discussion: Richard has proposed that all changes to TDS classes be approved before implementation. (Toby) Not everything in the TDS needs to be persistent [nor, by implication, in need of such approval]. For example, certain intermediate results may be placed in the TDS for convenience, but are only of of interest to a small set of packages and do not need to be written out. (Tracy) In some cases one may want to study such intermediate results offline, so it is desirable to be able to write them out, at least for certain non-production runs. (Heather) If we implemented a proper Gaudi persistency model, we would have this flexibility. (Richard) We can't expect to do this for Gleam v2r2.
CVS access: Do we need something more than social pressure to keep people from committing code to a package without the knowledge and consent of the package owner? Babar never has implemented any such controls. SLD had a system which grouped packages into "Sections", under the control of Section Leaders who could delegate control to others. Tracy suggests that the best fix is to improve communication [and perhaps understanding of certain fundamental aspects of the development environment. ed.] among developers. While we mull this over, Alex will investigate the feasibility of some form of (probably not foolproof) automatic control.
Nightly build: (Karl) Status from running the test program of a newly-modified package is now properly reported. Emails of problems are getting sent to package owners. [I can vouch for that one. ed.] Essentially, the system is working as designed, but there still can be problems in builds requiring at least one package at the HEAD: there is no automatic way to know what version to use of other packages with non-tagged HEADs. A couple different guessing strategies have been tried, neither perfect. To eliminate these problems, developers could specify HEAD versions as needed in their requirements file while development was still ongoing; by the time the package was to be tagged they would have to eliminate all the references to HEAD. (Richard) This is too much of a burden on developers; other nightly build strategies might correctly handle most of the cases we see. (Joanne) No fully automated strategy can always do the correct thing. Having to change the requirements file, and then change it back, is admittedly ugly; some other means for the developer to specify this information ought to be possible.
Action ItemsJ. Bogart Last Modified: 04-Aug-2004 15:40:49 -0700