Minutes of Software Tools meeting Feb. 23,1996 =============================================== PreseNt: J. Hobbs, A. Jonckheere, S. Krzywdzinski, Herb Greenlee, L. Paterno, Q. Li, H. Prosper (by phone) and S. Protopopescu (minute taker). Al Jonckheere presented a proposal for managing libraries that is a substantial departure from what we presently do. His suggestion is to make available snapshots of libraries as function of time. A software product (like FULL_D0RECO or D0GEANT,etc.) would have a version number that goes with a particular versions of object libraries (and anything needed to run that product). Releases will then be of the form LibA-1, LibA-2,... LibB-1, LibB-2,... : : and product version 1.1 may be a combination of LibA-3, LibB-1,..., LibZ-2. A particular D0LIBRARY version would also have a version number and with it a list of product version numbers that define it. It was generally agreed that this sounded like a good idea but some concerns were raised as to whether it could be implemented across multiple platforms. Another part of the proposal is to have two types of distributions in releasing software: 1) Release binaries from "standard" platforms supported at FNAL to "standard" platforms offsite. A "standard" platform must be running the exact same version of an operating system in a D0 FNAL platform. 2) Sources be distributed with BUILD files. Remote sites with non-standard platforms will have to build their own binaries and modify the BUILD files as needed. The question of whether the distribution should be by pull or push was brought up but no conclusion reached. The general feeling is that pull is preferable (less work for library managers). It was also proposed that there be only one test release version LibA_T and that test releases be under the control of library czars rather than D0 librarian. There was discussion on whether a test release should only be available on a limited number of platforms, basically only those involved in testing code. This would make libraries more reliable and encourage more rapid movement from test to general release. It was then realized that we need two kinds of "test" releases: bug fixes and code development. The LibA_T type of release is really for code development. On the other hand after LibA-1 and LibA-2 have been released we may realize that there is a bug in LibA-1 which is part of a certain product that may not work yet with LibA-2 so we need a release with a bug fix. So we would have to accomodate bug fix releases of the form LibA-1.001, it would replace LibA-1 and will not be treated as a new release. This is basically equivalent to pass releases in present production libraries. With these mechanisms perhaps we can dispense with production libraries although it was not obvious to everyone how practical the whole scheme is and how to avoid multiple branching in library maintenance. Laura brought up again the point that online code changes on a different time scale than offline, changes are needed immediately and one can't neatly separate bug fixes from code development. There was then a short discussion on a proposal on how to organize libraries. The proposal was to have one GENERAL library with utility software used throughout programs and then separate libraries for application packages with only write access to code developers of those packages. Qizhong reported on the joint meeting with CDF and CD division on code management. She mentioned that both CDF and CD favor using CVS and basically only one CVS repository for software. Their approach runs counter D0 present views, we are still thinking in terms of multiple libraries and defining a list of requirements before picking a product. If CDF and CD are committed to CVS it will be difficult for D0 to resist that and still expect help from CD. The CD approach is to have reserve scripts defining the modules that belong together in a product instead of having modules reside in separate libraries. We can think of applications and utility packages as products even though they are not necessarily independent of each other. From the single library we can construct a single object library to start with and solve the problem of dependencies and link order. But this requires advance knowledge of what code is part of a program if we want to avoid building one humongous object library rather than one tailored to each program. A product that finds all dependencies in a program would be useful here. It is not entirely obvious how one avoids linking code that we know will not be used at run time in a particular program. At the end of the meeting it was agreed that we need to proceed in parallel with the following items: 1) List of requirements for code management 2) Prototype CVS library 3) List of requirements for a user interface