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 <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


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