Reenabling Ada by default

[Richard Kenner]

    Grr, it's really frustrating that you use lack of expertise as an
    argument for maintaining your behavior.  

    So your argument doesn't wash and I see no reason you should feel
    entitled to behave differently than the rest of the community.

Just to be clear here that the "you" above does not apply to me personally
since I'm not one of the people making patches to the Ada front-end.  I do
work on the C part of the front end and the only reason why I don't check
them in directly is that it makes Arno's job harder when some changes from
the local tree are checked in and some aren't.

    One of the powerful ways people learn is by reading the patch list,
    *if* the patches follow our rules.  A self-contained patch with an
    explanation (and testcase if appropriate) is much easier to grok than
    a sterile jumbo batch.  You merely help maintain Ada's marginal status
    by keeping everything cloistered and the expertise all within ACT.

"Self-contained" is not nearly as easy as you think.  Ada is a quite large
language.  GNAT has been around for over a decade.  Although there are still
the occaisional "how did *that* ever work?" sort of bugs, most bugs found are
quite subtle and the amount of information needed to make their explanation
"self-contained" and understandable to people who aren't Ada experts is
large.

Neither Robert, Arno, or myself are saying this is impossible.  What I'm
saying is that the cost-benefit analysis of this is different from the
other front ends on both sides.  On the one side, the benefit of doing
it is far less because there isn't a set of people out there who are
eager to learn all about Ada (it would be nice if there *were*, but let's
be realistic!).  On the other, the cost is higher for the reasons
I've outlined.

    Also, "review" doesn't necessarily mean approve or reject.  Someone
    completely ignorant of Ada might simply catch a spelling mistake in a
    comment.  

Sure, but that can be done irrespective of whether they are one patch
or multiple in a message.

    Having the proper patch submission helps for posterity in case anyone
    needs to go back and examine it later.  The fact that ACT may have
    this information internally fails to help the rest of the world.

But the question, from a practical and realistic perspective, is whether this
information is really *useful* to the "rest of the world".  Who would want to
use it and for what purpose?  Before deciding to commit resources to
*produce* information, it's important to be sure there will be *consumers* of
that information.  And I don't see that.  The argument "if you make it, they
will come" doesn't seem that convincing to me in this case.

    Lot's of contributors work for companies that have customers, none of
    these customers use GCC head either.  When their customers report bugs
    against older versions of GCC, the patches are submitted correctly
    according to our rules and tested on every branch they are installed.

Arno tests patches with the latest branch. And I test my patches to the C
part of the front end with the latest branch as well.  The issue is the cost
of having *everybody* who develops front-end patches doing that as well.
You're talking about a dozen people here.