Re: who owns the code? was Re: Distinguishing type names from other identifiers

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Jeff Carter said

<<So, if I'm working on a package, I would not expect to come in one
morning and find an unexpected modification. I would know about any
modification in advance. Similarly, if I'm modifying a package, I would
want the original designer involved in inspecting my proposed
modifications, so he would not come in and find an unexpected
modification.

Of course, if I'm absent for an extended period (more than a couple of
days), I would expect to find modifications to what I've been working
on.

I doubt if this is foreign to either Robert Dewar or nabassi (Nasser).
This inclusion in the discussion of any modification is probably what
nabassi (Nasser) means by not touching a package without contacting the
original designer, if possible, and probably what Robert Dewar means by
everyone knowing about everything.
>>

Actually this would be foreign to me. Sure major changes do get discussed
in advance, but for minor fixes, and even significant additions, we use
entirely another scheme, which is to rely on a very extensive regression
suite (several million lines of code, in 25,000 files in 4,500 directories).

No one is allowed to make any changes without running this suite on their
changes and making sure that no regressions are caused.

We have found this suite MUCH more effective than another pair of eyes,
though another pair of eyes is always valuable for dealing with issues
other than functional correctness (e.g. efficiency and style).

There are two factors in the GNAT project which are relevant here:

1. We often need to fix problems for customers with a critical problem
in a very short time scale, while retaining quality control. Requiring
review cycles and discussions of any modification would be inconsistent
with the required rapid turn around time.

2. Compilers are a very nice case for testing. It is possible to build
very effective test suites (we use our own internal test suite I referred
to before, the ACVC test suite, and the DEC test suite, and between them
we have found them very reliable in avoiding mistakes in changes)

Of course we get MANY false attempts that do NOT get through the mailserver
(I don't know what percentage of mail server attempts, i.e. attempts ot
run our regression suite, fail, but it is high, I would guess 75%. It is
amazing how often a change that looks completely correct, and which any
additional pair of eyes would agree is correct, is wrong because of some
subtle interaction caught by some weird test in the suite!)

The way our mail server works is that you prepare your change as a patch,
and then send it to a special mailserver address, choosing which of several
machines to run on (normally any old machine will do, but sometimes if
you are making a change that might be machine dependent, you can run it
on a particular machine, or perhaps even more than one machine). Then
a few hours later you get a report, and you can't check things in unless
the report is clean

THen as a backup to this process, a message goes out to the group noting
the revision history of the change that has been made, and anyone who
usefully can will check the change to make sure it makes sense. Furthermore
than night the regression suite will be rerun (which catches the very rare
cases of conflicting changes -- we have not seen one of these in recent
memory, certainly not for a year), and also the ACVC and selected DEC
test suite tests are run.

We have found that this scheme works very well for us. Obviously it is
not necessarily applicable to other environments. In particular it is
often very difficult to construct a reliable test suite for many
applications.

Robert Dewar
Ada Core Technologies