Path: utzoo!mnetor!uunet!mcvax!ukc!stc!datlog!dlhpedg!cl
From: cl@datlog.co.uk (Charles Lambert)
Newsgroups: comp.software-eng
Subject: Coordinating Software Development
Message-ID: <407@dlhpedg.co.uk>
Date: 2 Feb 88 14:22:21 GMT
References: <12368277106.54.MDAY@XX.LCS.MIT.EDU>
Sender: news@dlhpedg.co.uk
Reply-To: cl@.co.uk (Charles Lambert)
Organization: FSG@Data Logic Ltd, Queens House, Greenhill Way, Harrow, London.
Lines: 63

> [tektronix!orca!stank@ucbvax.Berkeley.EDU  (Stan Kalinowski) writes:]
>
> [Several criticisms of the quest for terminology]

We're not really in dispute, here.  I'm sure that the engineering and
manufacturing disciplines have produced a wealth of good terms;  I'm simply
not aware of them all nor convinced that the ones I know are most appropriate.

I have three criteria for a good term: it should be concise, unambiguous
and evocative.

>We call that a "build tree" or, more specifically, a "build
>directory-tree".  (I don't know if Merriam Webster would approve of
>using dual attributive nouns
> ...
>We call the private instances "private build-trees" or "experimental
>build-trees".

This is just the kind of linguistic forest I want to avoid; it makes for
congested documents and long-winded speech.  Any noun requiring that degree
of qualification is ambiguous, and the resulting term is not concise.

> > [...3 reasons why I dislike the term "build"...]
> >i)	it is a verb doing service for a noun,
> >ii)	we need the verb anyway ("which build did you build?"),
> >iii)	it is not evocative - it doesn't portray what it means.
>
>I avoid cases like number ii) above, I would probably be more specific
>and say "Which configuration did you make?"

This further demonstrates that it is a bad term - it must be paraphrased
for clear communication.

>It seems to me that the term "view" is just as bad (if not worse) than
>the term "build".  The word "view" also has several meanings...
>...or it can be a projection of an object on an engineering drawing.

"View" seems evocative for just that reason.  It is the projection of two or
more (sparsely populated) "builds" to produce a superimposed collection.  A
"build" is to a "view" what a scalar element is to a vector. This is
essential to the way we share stable (or beta-testable) sources.

>By the way, we avoid maintaining multiple, actively
>used, versions of a given module's codee whenever possible.  We have
>found that it is very difficult to propagate bug fixes common to
>several product lines to each product without having to "un-fix" some
>bugs that are unique to a product.

Avoiding multiple concurrent changes to the same module is ideal - an ideal
we are unable to maintain in practice.  The mechanisms of source-sharing
and "reconciliation" in our prototype system are intended to take the pain
out of propagating fixes amongst product lines and amongst concurrent
developments of the same line.

Most of the responses I have received to the latter idea suggest that it is
hopelessly ambitious.  Our experience doesn't yet support that view.  There
are some subtle complexities in merging concurrent developments but we
are presently managing by a combination of automation (using SCCS delta
inclusion) and assisted inspection.  We have not yet exhausted the potential
for automatic assistance.

--------------------
Charles Lambert		Data Logic UK, Harrow, England.