Re: source mgt....[_HAS_ gcc relevance]

[dewar at gnat dot com (Robert Dewar)]

> Well, my ideal is that changes to the mainline should occur only
> _after_ they have verifiably passed all the available tests on a wide
> range of platforms (a process that can be fully automated) and the
> changes have passed senior engineer reviews (a process that can be
> facilitated by substantial automated assistance).  Mainlines should
> increase in quality in a strictly monotonic fashion -- that's the
> essence of what "gatekeeper management" is all about.  Neither GCC nor
> lk have that property -- though better tools can do much to put us
> there.  With good tools, the release manager can ultimately be
> replaced by shell scripts.

with GNAT, we let everyone within ACT, which is quite a diverse set of folks
about 35 in all, change anything in the mainline, but we guarantee the
monotonic properly (I agree this is crucial) by enforcing fairly strenuous
requirements on anyone doing a change. No change of any kind (not even
something that is "obviously" safe) is allowed without doing a complete
bootstrap, and running the entire regression suite (which is pretty
comprehensive at this stage) first. Now we only require this on one target
for changes that are expected to be target independent, so it is possible
to have unanticipated hits on other targets. We deal with this by building
the system on all targets every night and running the regression suites on
all targets every night. If the reports in the morning indicate a problem,
then it is all hands on deck to fix the problem.

When we get GNAT properly integrated into GCC, which involves several
things still to be done:

1. We need to get to a release point internally where the GCC 3 based GNAT
passes all regression tests etc. We are close to this, and expecting to
do a beta release in January on selected targets (should include Solaris,
Windows, GNU/Linux, HPUX).

2. We need to get the sources and our internal source procedures more
amenable to GCC style (e.g. we have removed the version numbers from
our sources, and adjusted all our scripts for this change recently).

3. We need to establish the ACATS test suite so that anyone can run it. This
is not as comprehensive as our internal test suite (which is not distributable
since it is mostly proprietary code).

4. We need to set up procedures so we can run and test changes that others
make against our internal test suite.

... then hopefullly we can duplicate at least some of these procedures
in a manner that others outside ACT can follow a similar path. We regard
this kind of automatic testing as absolutely crucial.

> With good tools, the release manager can ultimately be
> replaced by shell scripts.

I don't believe that, based on our experience where we have elaborate
scripts that try to automate everything, but you still need a release
manager to coordinate activities and check that everything is working
as expected.