This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Why not gnat Ada in gcc?
- To: dewar at gnat dot com (Robert Dewar)
- Subject: Re: Why not gnat Ada in gcc?
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Wed, 01 Nov 2000 22:31:32 -0700
- cc: gcc at gcc dot gnu dot org, kenner at vlsi1 dot ultra dot nyu dot edu, rms at gnu dot org, rth at cygnus dot com
- Reply-To: law at redhat dot com
In message <20001102033112.E5A9334DAF@nile.gnat.com>you write:
> Yes, but of course you cannot deal with daily instability for actual
> commercial development for large scale customers who depend on absolute
> stability.
Correct. But these issues can (and should) be handled internally within
ACT, Red Hat and whomever else is trying to build commercial products based
on GCC.
This was one of the major problems with GCC2 development if you recall --
the stability needs of a particular company basically brought new development
to a standstill.
> Our internal development tree always maintains close to absolute stability
> (we do not permit even the most minor change to be made without FIRST
> running our entire regression suite, and no change can be made if it
> causes any regressions at all). Then we run all versions on all targets
> every night to absolutely ensure that no regressions have occurred.
> This testing depends of course on large volumes of proprietary code
> as well as proprietary test suites. We do also use the open ACATS
> suite, but that's only a small part of the testing.
Fine. But that doesn't (and shouldn't) have *ANY* affect on the external
tree.
> I don't think that kind of very controlled development is appropriate
> to the open tree, as you say, in this environment people can indeed deal
> with daily instability.
Right. That's why when you import code from the open tree you have to
beat it into an acceptable state. That's part of playing the open source
development game.
> It is interesting to note the fuss about Redhat distributing a non-official
> release of GCC, where poeple worried about instability.
Particularly when they aren't aware of how much that code was tested, debugged
and fixed.
> In our internal
> environment we distribute daily builds to customers to fix bugs as needed,
> because we know that they are completely solid. I don't think anyone
> would suggest that daily builds from the open gcc tree could be immediately
> be integrated into production environments.
Nope. I would never suggest that. That's why Red Hat has a process for
importing code from the external tree and beating it into shape before it
gets exposed to customers.
jeff