From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3ba18d626276a71e X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Towards a free GNU Ada Date: 1997/07/06 Message-ID: X-Deja-AN: 254984892 References: <33BBB704.167E@velveeta.apdev.cs.mci.com> <5pn0u4$1cs@kiwi.ics.uci.edu> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-07-06T00:00:00+00:00 List-Id: Roy says <> 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