Re: Why not gnat Ada in gcc?

[Jeffrey A Law <law@cygnus.com>]

  In message < 10010121135.AA01748@vlsi1.ultra.nyu.edu >you write:
  >     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.
True, but keeping it locked away at ACT virtually guarantees that you never
get any contributors at all.  That's how things have been since the GNU Ada
project started.

  >     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.
It's not a proposal, it's current reality.  ACT employees have exclusive
access to the GNU Ada sources.  


  > 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.
The way to manage this is to test the hell out of the tree when you bring in
changes from the net *before* you check those changes into your internal
repositories.  That's what Cygnus and later Red Hat has done for years.

  > 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.
Then you need to build policies and procedures for keeping some code local,
again, Cygnus/Red Hat has used various procedures to manage this for a long
time.  I'm more than happy to describe our policies and procedures if you are
interested.

Please keep in mind that those issues are ACT's problems and should not be
a consideration for how to manage the GNU Ada repository.

  > 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 mak
  > es
  > 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.
Any bulk merges need to be from the net sources to your internal sources.
Any other method would put ACT into a privileged position in regards to
installing changes into GNU Ada.

jeff