From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.9 required=5.0 tests=BAYES_50,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uwm.edu!linac!att!ucbvax!TARTAN.COM!ploedere From: ploedere@TARTAN.COM Newsgroups: comp.lang.ada Subject: Re: CM tools and Ada Message-ID: <9103270258.AA01923@tartan.com> Date: 27 Mar 91 02:58:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet List-Id: Re: Lisa Lane (3/15) and Jim Showalter (3/17) messages For the last two years, we have designed and implemented a Configuration Management Assistant (CMA) under the STARS program. CMA addresses a number of configuration management issues, particularly in the setting of software reuse, e.g., the integration of systems from independently versioned and administered subsystems. The main theme of CMA is to help the user decide BEFORE building the system, whether the configuration is likely to (not) function properly and to pin-point potential troublespots. Put in Ada terms, CMA will for example tell which Ada libraries need to be combined to form a complete system configuration, and which versions of these libraries fit together. We are most interested to hear from the general Ada user community what their requirements are on CM in Ada projects. Particularly, we are struggling with the issue on where the boundaries are between a tool like CMA and source and object version control, Ada librarian functionality, release policies and procedures, engineering change request systems, etc. While we could incorporate all such functionality in CM, we would prefer a less monolithic approach. Which other tools should we interface with ? If you have feedback that you don't want to post to the general public, or if you want to know more about CMA, please send e-mail to ploedere@tartan.com. Erhard Ploedereder Chief Scientist Tartan, Inc.