Re: Towards a free GNU Ada

[fielding@kiwi.ics.uci.edu (Roy T. Fielding)]

[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/