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: fielding@kiwi.ics.uci.edu (Roy T. Fielding) Subject: Re: Towards a free GNU Ada Date: 1997/07/07 Message-ID: <5ps4eg$bo1@kiwi.ics.uci.edu> X-Deja-AN: 255380392 References: <33BBB704.167E@velveeta.apdev.cs.mci.com> <5pn0u4$1cs@kiwi.ics.uci.edu> Organization: UC Irvine Department of ICS Newsgroups: comp.lang.ada Date: 1997-07-07T00:00:00+00:00 List-Id: [regarding the notion of a publically maintained problem tracking system for GNAT] dewar@merv.cs.nyu.edu (Robert Dewar) writes: >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. You jump from one assertion to another without any basis. If you classify myself and my customers as the "hobbyists in the Ada community", then it might be true that we are capable of fiddling with streams of uncoordinated and insufficiently tested patches. We are rarely "happy" to do so, and would obviously prefer coordinated and sufficiently tested patches, but when the choice is finding and fixing a bug or postponing a project until ACT makes a public release, the choice should be obvious. A public tracking system lets us share that work instead of each doing it individually. Does this impact reliability? Yes, but only in a positive way. If the fix is wrong, it will be corrected and the correction attached to the initial report. That is one of the advantages of a tracking system over just posting reports and fixes to netnews or a mailing list. >I don't know quite what makes you think that GNAT development is >haphazard, but let me give some idea of how we proceed internally. I didn't say it was. I said that, in order for a separate Ada95 compiler project to succeed, it would need to be less haphazard than the existing GNAT development process, regardless of whether it was done by a corporation, a joint support contract, or a community of volunteers. There is no correlation between community-based development and haphazard development processes, which is what the poster implied. However, there is often a correlation between haphazard development processes and the success of a competing project. >... >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. Obviously, someone who was "fiddling" wouldn't be running regression tests on bugs that they have never encountered. However, there is nothing stopping a community from building a community-supplied and public database of test cases that surpassed any private database. It takes work and real people to support it, but to say that it can't be done is just foolish. Besides, there is nothing preventing ACT from testing the provided fixes, or providing its own patches which have been tested against your private regression and build process. The choice of whether or not to do so would depend on whether or not you are interested in supporting the community beyond mere releases. In any case, such a project would not be dependent on ACT's support, nor would it be subject to ACT's approval. >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. That is, in my opinion, ACT's prerogative. However, I also know that it is detrimental to my work, and thus negatively impacts my customers. We are getting a bit tired of telling DARPA and the AJPO that our software works fine on private versions of GNAT, but has never run under a publically released version of the GNAT compiler. If the wavefronts were named and publically released, then we would have a means of tracking changes to the compiler and running our own build tests, and a means of indicating to our customers what is necessary to compile our software. It doesn't mean that we would always run such tests, just that we would have a *choice*. Furthermore, it would give us (and others) the chance to identify problems before the stable release. >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 proprietors 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. Obviously, the code placed in the reports of a public tracking system would have to be public. There is no requirement that the public tracking system contain all of the data from your private reports, nor that it even contain all of the known problems. It doesn't have to be perfect in order to be useful. What it provides is a focal point, which is something that ACT doesn't even provide its paying customers. >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 see the community as containing both types of users, and would prefer that both be given the choice of receiving stable releases and unstable releases. You claim that giving non-customers wavefront releases will make support impossible, but you don't provide support for non-customers in any case (even less than most free software projects provide free support). Instead, you claim to know what is best for us, and thus the right to choose for us. That is the real source of our disagreement. >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. I read the hypermail archive periodically. Building a community requires more than just communication; it requires a common purpose and the ability to contribute to that community, with the tangible results being visible to the rest of the community on a near-immediate basis. I'm not even sure that such a community is possible in the Ada95 world (lack of people is the primary concern), but I do know what is currently making it impossible. Don't be fooled into thinking that these are just off-hand remarks. I have been building such communities for the past four years as part of my research in software engineering. Right now the most significant difference between the Ada95 world-view and the world-view of languages such as Java, Perl, and Python is this self-crippling notion that a secrecy is necessary to control a software project and to provide high reliability. In my opinion, Ada95 will have no future unless it makes community-based development *easier* than it already is for other languages. It needs to be easier because Ada95's language entry-barrier is already much higher than other languages. >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. If that is your definition of "enthusiasts", then I'd say I am not one. My first priority is that the compiler compile, and the real-time system support, Ada95 as defined by Ada95. After that comes support for debugging, particularly on multithreaded code. After that would be an easier installation process, but I understand that is primarily constrained by the intertwining with GCC. In short, I want reliability, correctness and robustness, but do not believe the best way to obtain it is through a closed development process. Proprietary projects have to live with those shackles; we don't. Everything I have suggested has been demonstrated to improve reliability, correctness and robustness on other software projects. It also tends to improve design for extensibility and portability, and in general results in more people being actively involved in using the product and producing related software. These characteristics can be seen in libwww-*, Apache, Linux, FreeBSD, SSH, etc. If you think you understand the nature of software engineering and the limitations of software development processes better than I do, then you can disregard my comments. However, you have a long way to go before you can understand the needs of my customers. ...Roy T. Fielding Department of Information & Computer Science (fielding@ics.uci.edu) University of California, Irvine, CA 92697-3425 fax:+1(714)824-1715 http://www.ics.uci.edu/~fielding/