comp.lang.ada
 help / color / mirror / Atom feed
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Towards a free GNU Ada
Date: 1997/07/06
Date: 1997-07-06T00:00:00+00:00	[thread overview]
Message-ID: <dewar.868186883@merv> (raw)
In-Reply-To: 5pn0u4$1cs@kiwi.ics.uci.edu


Roy says

<<If you are concerned about the continued development of GNAT as a
platform for free software (as I am), then I think the most constructive
project would be a public, Web/e-mail problem tracking system for GNAT
that allowed everyone (ACT, customers of ACT, and non-customers) to
see what known bugs exist, to post potential fixes, and provide some
focus for the community.  It isn't an easy thing to provide, but it
is certainly a prerequisite to any other Ada95 compiler effort.  And,
I think it would help ACT as much as it would the rest of the community.
>>

RObert replies

This might appeal to the hobbyists in the Ada community who are happy to
fiddle with a stream of uncoordinated and insufficiently tested patches,
but it would be inimical to the interests of the wider Ada community
that needs reliable products. The need for reliability extends both
to paying customers, and perhaps even more to those who rely on free
public versions, which they must use without much support.

Even for those who do know the technology well, formulating a correct
fix to a problem is not easy. We get a stream of suggested fixes from
people who know GNAT pretty well. In nearly every case, the person
has correctly identified a problem, but produced a fix that is either
incomplete or plain incorrect.

I don'q know quite what makes you think that GNAT development is
haphazard, but let me give some idea of how we proceed internally.

If one of the GNAT developers develops a fix for a problem, or an agreed
on enhancement, then the modification is initially developed as a patch
to the current development sources.

This patch is submitted to a mailserver that runs our entire regression
suite (about 4100 diretories, totalling over 25,000 files, and over
two million lines of code). A couple of hours later, a mail message
indicates if the change has caused any regressions. If there are no
regressions, then the change can be checked in.

That night, automatic scripts run on multiple targets, which rebuild the
compiler completely from scratch, with a full bootstrap that starts with
the most recent public release. These scripts test that the bootstrap
succeeds, run the entire ACVC suite, and rerun the regression suite.

In the morning all developers receive a report on these nightly runs,
and if any problems have developed, fixing them is the highest priority.

Only if the nightly run is completely successful, do we qualify the
build as a distributable wavefront. Distributable in this case means
that we will provide it on an extremely limited basis, on request, to
supported customers who need the wavefront to fix an urgent problem.

Note that this kind of regression testing is out of reach of informal
fiddling. For one thing, the great majority of the code in the critical
regression suite is proprietary, for example it includes large chuncks
of the DEC test suite, as well as a lot of customer code, that the
customer has been willing to entrust to us only on the basis that
we will carefully protect it. It is also the case that the configuration
control that is needed requires very strong control and management.

You need to remember that the entire thread here develops from one
individual who is demanding to get a version of GNAT that we do not
think is ready to release. Yes, of course, we all want 3.10 to be
finished and out there as soon as possible. We have a team of people
working full time towards that goal, and all I can say is that we
simply will NOT release 3.10 before we feel it is ready for release,
no matter how loud people yell.

You point to Linux as an example of your model working, but in fact Linux
is a system based on many components, including the GNU software. The
latter is in fact at as carefully controlled as GNAT. You do NOT see the
snapshots du jour of GCC in the Linux sources. Similarly, the kernel itself
is also very carefully controlled, and in addition there are several 
companies providing formal support which carefully control what they support.

The sources of GNAT have always been available, and large numbers of
people, particularly the hobbyists build from sources. We are always
delighted when people from the community DO contribute to GNAT, and
indeed in a couple of cases have hired such people (Doug Rupp developed
the DOS port of GNAT, and is now a full time employee of ACT, Geert Bosch
did some very nice work on the OS/2 port, and we hired him as a consultant
to continue the support of this port). However, relatively few people have
achieved a sufficient knowledge of what is going on in this highly complex
system to really have dug in.

It is always nice to receive a bug report together with a fix, and it has
happened a few times for runtime library components, but almost never for
the core of the compiler itself. And this is true despite a very strenuous
effort to make the sources accessible.

The idea of a public tracking system for GNAT bugs is unworkable in
practice. Why? Because the majority of code involved in such reports
is proprietary, and there is no way that the proprieters of such code
will post it. We quite often get bug reports that contains tens or
even hundreds of thousands of lines of such proprietary code.

I think a big difference here is what your view of the community is.
You see the community as a group of energetic hobbyists who want to
play with the latest versions of GNAT, develop and trade patches, etc.

We see the community as a group of serious users who need stability
and reliablity, and are not interested in always trying out the latest
patches and new features. Our customers are often quite reluctant to
switch to new versions, and that makes perfect sense to us.

I do not know if Roy is subscribed to chat@gnat.com, as far as I can
tell he is not, but I am not sure I am checking the right address. The
idea of chat@gnat.com is to develop to a small extent some aspects of
this informal community. 

In practice, most of our support activity is not in fixing GNAT bugs,
but rather in helping people use the Ada 95 and GNAT technologies
effectively and efficiently in the context of the specific problems
that they are trying to solve. The idea of chat@gnat.com is to provide
this kind of help, and it does so to some small extent. It would also
be perfectly appropriate to post GNAT patches and fixes here if people
discover such, but that has never happened.

We certainly are not about to participate directly in any such effort
of a central bug registry. For the reasons I give above, this is 
impossible, even if it were desirable. We certainly are NOT about
to post our fixes one by one as we develop them. This is a recipe
for a completely out of control mess.

I have been involved in a number of commercial compiler projects, including
Ada 83 compilers, and, while ACT's software process may still not be ideal,
I can say that it is greatly superior to anything I have previously 
encountered in the industry.

Sure, I understand the frustration of the enthusiasts who would just love
to get their hands on the development version every day and fiddle, but
I am afraid their interests must take second place to the needs of the
Ada community that is interested in stable and reliable products and
wants to see from each GNAT release not only neat new features, but also
a general improvement in reliability, correctness and robustness.

Robert Dewar
Ada Core Technologies





  reply	other threads:[~1997-07-06  0:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-07-03  0:00 Towards a free GNU Ada James Rogers
1997-07-05  0:00 ` Roy T. Fielding
1997-07-06  0:00   ` Robert Dewar [this message]
1997-07-07  0:00     ` Roy T. Fielding
1997-07-08  0:00       ` Larry Kilgallen
1997-07-08  0:00         ` Roy T. Fielding
1997-07-06  0:00   ` Michael F Brenner
1997-07-06  0:00     ` Ada User Reports Larry Kilgallen
1997-07-08  0:00     ` Towards a free GNU Ada Robert Dewar
1997-07-08  0:00     ` Roy T. Fielding
1997-07-05  0:00 ` Robert Dewar
1997-07-10  0:00   ` Ronald Cole
1997-07-06  0:00 ` Chris Morgan
1997-07-06  0:00   ` James S. Rogers
1997-07-06  0:00     ` Chris Morgan
  -- strict thread matches above, loose matches on Subject: below --
1997-07-06  0:00 Re " Robert C. Leif, Ph.D.
1997-07-08  0:00 ` Robert Dewar
1997-07-15  0:00 Robert C. Leif, Ph.D.
1997-07-16  0:00 Robert Dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox