Why not gnat Ada in gcc?

[Richard Kenner]

    But it would make it possible for folks to build & test it over time.  ie
    you'll be able to say "oh, that change addressed an Ada bug that is in the
    regression testsuite", so before you twiddle that code any further make
    sure that your change doesn't regress the Ada compiler.

Sure.  I don't think anybody (certainly not me) is arguing against putting
GNAT in the tree, among other reasons for the one you mention.  I'm just
pointing out that I think it's highly unlikely that putting it there will
somehow bring lots of potential GNAT-modifiers out of the woodwork.

    And fundamentally ACT policy of having *exclusive* access to the GNAT
    sources is counter to the principles of open development of free
    software IMHO.

That's also a strawman, since nobody has proposed that either.

    *BUT* we didn't do bulk merges *into* the official sources.  That
    *IS* what ACT does with the GNAT tree.

I don't understand your tense here.  Since no procedure has been set up yet,
nothing can be in present tense and any guesses as to the future are
speculation since nothing has been decided.

For those who don't understand what I was getting at, the main reason that
somebody offering commerical support for GNU software needs their own private
tree has to do with changes done by others.  These affect both QA issues and
timing.  For example, one service ACT provides to its customers is a
"wavefront" compiler which incorporates a fix to a critical bug that a
customer reported.  That means it needs to be able to ensure that a given
night's build meets QA.  It's reasonable for ACT to ask its developers to
avoid non-critical checkins from time to time, but not for it to prohibit
such in a public tree.

There are also occasional issues the other way.  Sometimes, meeting a
customer need and deadline requires making a change that isn't "ready for
prime time" and that will get cleaned up later.  Such changes should not be
placed into the poublic tree until they are.

Given that two trees are needed, there will always be the issue of merges.
Whether they are done with periodical bulk merges or change-by-change, it
takes significant resources to do them.  Which of these takes the most work
is a strong function of how many changes are made by others.  If others makes
lots of changes (like the GCC case), the most efficient way is to merge
change-by-change.  If there are very few changes made by others, the most
efficient is to do periodic bulks merges.  So the comparison with the way
Cygnus used to do it is not as relevant as it might seem.

I think what Laurent was trying to say was that it's best to not make that
decision now, but instead to put the tree out there and *see* how many people
make changes over a period of time and let that strongly influence the
decision of what the best policy is.  I agree with that approaach.

    Cygnus/Red Hat has the same kind of access anyone else does as far as
    GCC is concerned.  That is definitely not true for GNAT development.

Again, that has tense problems since GNAT has not been put into the tree yet.