This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Why not gnat Ada in gcc?



  In message <20001102034315.3D20E34D82@nile.gnat.com>you write:
  > <<The development of the ia64 port (IMHO) was severely limited by the NDAs
  > that were forced on the developers by Intel and others.
  > >>
  > 
  > NDA's should not be permitted in this environment
That's your opinion and it has a lot of merit.  However, as much as I'd 
prefer otherwise, customers often want to ensure that information about
their new chips and the like are not released indirectly via compiler
development before the chip itself hits the market.  It's a part of the
business and Cygnus/Red Hat deals with it as best as we can.

That means that after the NDA is lifted (and there's always clauses in our
contracts which trigger removal of the NDA) we contribute the port (or
whatever work it is).  From that time on additional development to that
code happens in an open way.

However, we also go to great lengths to deal with infrastructure issues
in a very open way by describing issues in generic terms that do not 
violate NDAs and trying to get them resolved openly.  By the time the
NDA'd work is done all that's usually left is one or more new files which
contain the NDA code.  After the NDA is lifted we then submit the formerly
NDA'd code for inclusion in to the official sources.

For radically new development that isn't NDA'd we often set up a branch
so that all developers can collaborate on development in an open way without
affecting folks that do not want to be involved until that radically new
development is approaching stability.  I think the garbage collector
development for GCC is an excellent example of this.

  > In particular, the open tree will of course be more source oriented,
Correct.

  > whereas most current users of the public version of GNAT are interested
  >  in turnkey packaged binary builds, rather than building for themselves
And that's perfectly fine.  In no way do I want to discourage you from doing
this.

In the end, what I want is for anyone who wants to work on GNU Ada to be able
to do so -- with the same rights and privileges as ACT.  I fail to see how that
can possibly happen if ACT does bulk merges from the ACT tree into the
gcc.gnu.org tree.

Or let me put it another way -- would anyone here be comfortable if Red Hat
dumped all its changes for a period of time (say a month) into the tree without
any kind of review or discussion at once as a single large patch?  I doubt
it :-)  Nor do I believe any company or individual should have that kind of
privileges in the source tree.

That doesn't mean you can't do major development -- it does mean that you have
contribute independent hunks of development separately and that the usual daily
fixes need to be submitted & committed independently in a timely fashion.

ie, blasting in a few hundred kbytes of assorted random fixes is not the
way to go, but a few hundred kbytes of a single conceptual change for a
new feature may likely be acceptable as long as you can make a case that
the change is a good one to make.

  > Anyway, it seems to me that the right steps are to work as quickly as
  > possible to get the GNAT sources integrated into the gcc tree,
Yes, absolutely.

  > then try to work towards the goal of keeping the open tree as well
  > syncrhonized as possible with our internal development.
Yup.  But that's a burden that is ACT's burden alone -- anything else puts
ACT in a privileged position.

  > We are currently working to stabilize the current set of sources to
  > make a new release, 3.14, and as soon as this is ready for beta release,
  > which should be very shortly now, we will make these sources available.
  > We also have to resolve some remaining issues of the integration with
  > GCC 2.9x, but that work is also coming along very well.
Excellent.

Again, to reemphasize, in the end what I want is everyone on a level playing
field within GCC development and I fail to see how than can happen if ACT
is doing bulk merges from the ACT repository into the gcc.gnu.org repository.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]