Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!cernvax!cgch!warw From: warw@cgch.UUCP (Anthony R. Wuersch) Newsgroups: comp.software-eng Subject: Re: Source Code Control Keywords: configuration, SCCS, mail systems, organizations Message-ID: <842@cgch.UUCP> Date: 27 Jun 89 09:57:44 GMT References: <133@tirnan.UUCP> <9630002@hpirs.HP.COM> Sender: news@cgch.UUCP Organization: WRZ, CIBA-GEIGY Ltd, Basel, Switzerland Lines: 116 In article <133@tirnan.UUCP>, john@tirnan.UUCP (John Richartz) writes: > > [... Having used] either SCCS or RCS[, I] find that the structure > is generally not in place to provide a development model that > allows for realistic development of a Product and any variants and > descendents of it (admittedly this often results from lack of > organizational focus on the problems). . . . ("I think," "I believe," or "I would suggest" applies to all of this. I'll leave these phrases out of the rest.) Let's try an organizational focus, known where I've been as "release engineering". It suggests a context, a problem, and a solution that non-developers understand. Based on that, some evaluation criteria. Grant that "development" is embedded in a larger organization. Grant that Products flow out of smaller suborganizations, one of which is "development". The organization claims that Products have stable forms and properties. The organization can reproduce Products and can distribute them. Products circulate in the organization and go out to users. [NOTE: a post-release bug fix is an example of a Product] Finally, grant that a lot of important talk in the organization refers to specific Products and sets of Products. People inside and outside the organization need to precisely distinguish between one Product and another, and between one set of Products and another set of Products. People also need to be able to refer to a single Product, or to a set of related Products. Developers may *not* need to precisely distinguish between one Product and another, however, if the difference is only a small configuration or a couple of keystrokes. Developers may delay specificity until the later stages of a design. Developers also tend to forget the fine points of Product reproduction, such as the need for a standard environment in which Products will be assembled. One rarely sees a machine in use by developers which keeps its original standard environment. Release engineering is a standard group chartered by the organization to guarantee the proper identification of Products, and to ensure that the organization can reproduce Products by assembling them from parts in standard environments which are available for the long term, using available techniques. An organization needs release engineering when distinguishing between and referring to Products is *more* important to most people in the organization than it is to developers, and when Product reproduction occurs *away* from normal arenas of development. A proper ID must be well-defined, i.e., *any* trained person (not just developers) should be able to answer a question "Does ID $x cover Product instance $i?" with the correct yes or no. Expressed differently, an ID is well-defined if those trained to know what it means can and do use it correctly. The release engineering (RE) group: + executes and improves the assembly process for a Product in a plain standard environment, until it knows the Product is reproducable. It works from instructions given by development, and a goal which development claims that following the instructions will achieve. Development and the group work together until the group is satisfied. + secures all parts for assembly so that they aren't lost or changed; guarantees that all initial conditions for assembly are fulfilled now and for the expected life of the Product. + approves IDs for Products. + accurately answers questions of what Products an ID covers. + ensures that Product IDs are visible (for instance, in software and in report forms) and used correctly throughout the organization. Configuration in development takes on a meaning in relation to release engineering. A configuration is a change to a product which leads to a new Product ID approved by release engineering. SCM systems with mail system interfaces would interest me a lot. For instance, SCM systems which set up IDs so that mail could be sent to a release ID as a bulletin board for anyone interested in the release, and so that mail folders could be aggregated for people interested in a release and following subreleases (i.e., the 1.1, 1.11, 1.12, 1.13, ... mail). I would say just one thing more: It is almost always easier to give missions [charters] to *people* and let them gain experience in carrying them out, then to design systems which will do them better than the people. A learning curve is better than none. For instance, no SCM system I know of satisfies the release engineering *visibility and correct use* requirement. Nor can any SCM system show that IDs are well-defined in the organization. RE needs good people. One RE group I worked with just wanted source code on a tape, instructions on a separate sheet of paper (handwritten was fine if they could read it --- they'd transcribe and edit it anyhow), and binary to "cmp" a processed result against. Simple instructions preferred. Complex scripts frowned upon. Instructions could refer to product IDs already approved by RE. Assembly took place on a standalone machine not connected to any network. All user-visible software had a standard call to read a file containing the product ID. The RE group wrote this file and ran the software to see that its product ID was visible. These are my opinions alone. Toni Wuersch (CIBA-GEIGY Scientific Computing Center) c/o CIBA_GEIGY AG, R-1045.3.32, P.O.Box, CH-4002 Basel, Switzerland UUCP: warw@cgch.UUCP ( ..!mcvax!cernvax!cgch!warw ) Internet: warw%cgch.uucp@uunet.uu.net Phone: (+41) 61 697 31 43 BITNET: warw%cgch.uucp@cernvax.bitnet Fax: (+41) 61 697 32 88