Software Tools Minutes 17 November 1995 9:00 AM - 10:15 AM ====================== Present: Krzysztof Genser (scribe), Alan Jonckheere, Qizhong Li-Demarteau, Lee Lueking, Laura Paterno, Serban Protopopescu The meeting was devoted to the second part of Alan's presentation on the Code Management, and specifically to the 'Features of "The Next Generation Library"'. The original text presented by Alan can be found in: d0sft::usr$root3:[jonckheere.tools]d0library.txt Here comes the relevant part of Alan's text interleaved with the comments by those present at the meeting: Features of "The Next Generation Library" We are assuming that the emphasise of our code development will be be moving away from strictly VAX based development to a more egalitarian development environment. In the short term this would be a switch to UNIX environments (note the plural) as the emphasis. 0) I see no major problem with the form of the D0Library as a repository, ie) separate "products" with a Czar who controls it's contents and releases. It needs reorganization as to what products are maintained and what goes into each of them. Each "product" or sub-product (ala D0Geant) should have a fairly small, close knit group of developers. comment: Library czars should be more knowledgeable about the library structure, contents and intra & inter library dependencies; 1) The Archive can be on any machine (VAX, UNIX, NT...) but we need the equivalent of CMS on that machine with most of the features of CMS, including it's Groups, Classes and ability to create text output with element name substituion so we can create the release command scripts. This could stay on VMS for the foreseeable future, until something better comes along. So I see no problem with the archive features of the library. 2) We need an easy way to update the archive remotely. You shouldn't have to login to the archive machine to update your library, but maybe you want that as part of your control of the archive. RShell could be used perhaps. If we have machine dependent blocks (D0Flavor) this update program needs to check and if necessary set the blocks to the default flavor. comment: fully uniform interface on all the platforms is very desirable; element reservation/locking mechanism is mandatory; history records (log) is mandatory; 3) We need to have a way to automatically compile code on several different platforms *before* it goes into the archive. comment: compiling code on more than one platform makes code more portable; it should be possible (but not necessarily easy) to alow for a code which works on only one platform (or subset of platforms) e.g. very specific online code etc...; 4) We need some sort of code review/verification for at least *some* of the release types. comment: good management tools for czars are needed to verify code, check for dependencies, duplications etc...; collaboration wide uniqueness of element names is mandatory; using unique routine prefixes helps some, but makes it difficult to move routines across libraries if need arises; it should be possible to lock some elements almost permanently (e.g. ZEBCOM today); 5) We need some way of making rapid updates/corrections to at least some of the release types (czar actually does them?) 6) We need to rethink the various kinds of releases we need in light of the above. I'd recommend something like: a) ALPHA (private), have to have this. Unreviewed. b) TEST/CURRENT/OLD where TEST might be redone frequently, but would *automatically* become CURRENT after a *short* time. Current would then become OLD. Test would be done by the CZAR and would replace both BETA and GAMMA. CURRENT would replace (today's) TEST and OLD would replace OFFICIAL. Perhaps TEST would only exist at some small subset of sites, but these should include at least one of each flavor of operating system. CURRENT/OLD would go everywhere (via AFS?) This might be done by the Czar. Reviewed? CURRENT and OFFICIAL *should* be reviewed, but one thing I think we *really* need is that TEST is temporary. Otherwise CURRENT and OFFICIAL become useless. Everyone would use TEST just like they do now. c) PRODUCTION and PRODUCTION PASS would remain, but hopefully could be improved. I don't know how though. comment: periodic (once, twice a year?) compatible (working) full d0library releases (a'la production reco) are desirable; working "backup" version for each library at any given time is mandatory; 5) Distribution needs improvement. a) It's been suggested that we use AFS, a distributed file system to do this. With AFS code is cached locally only when it's needed. Thus the distribution would be automatic and on demand only. I have no idea how to guarantee that the code will work though. This is easy to do for the source code. But the object libraries and executables have so many dependencies on the particular operating environment that I don't see how it'd work. b) One of the major problems we've had lately is changes in the various operating system environments. The run time libraries, versions of compilers, versions and types of network transport systems, versions and types of graphics systems... These mean that an executable linked on one machine won't run on other systems even of the same "flavor". How do we handle this? comment: to effectively use human resources it is very desirable to concentrate on a specific set of platforms, operating systems (versions), compilers (versions) and other utilities and their versions which will be supported. It would be guaranteed for each d0library to work in such a supported set of environments. In this scenario institutions having different environment would need to either make their systems compatible with the supported ones or make a port of the desired libraries to the other systems themselves.