Re: Time schedule?

[Jeffrey A Law <law at cygnus dot com>]

  In message <199910190111.SAA23672@kankakee.wrs.com>you write:

  > I disagree.  I think we should include it in, now, regardless of the
  > state it is in.
I strongly disagree wrong with that attitude.

There is a significant difference between dropping in something that is
basically OK and just needs polishing around the edges and dropping in
something that needs major revamping before it's in the right neighborhood.

We do not know where the gpc code sits at the current time.  Last I looked
there were some major problems, particularly in how it interfaced into
expr.c and the debugging code that were totally unacceptable.  Worse yet,
nobody from the gpc camp even knew why the changes were needed (or even if
they were still needed).

I'm not trying to slam the gpc folks, but that's not a hunk of code we're
likely to accept unless it has been significantly improved.  I sincerely
hope it has because I want to see GCC incorporate gpc in the hope that it'll
have the same kind of positive effect incorporating g77 had.

  > Once it is in, people can contribute fixes for
  > whatever brokenness is left, if and as they care.  Without it in, out
  > of sight, out of mind.  (I'm assuming it at least doesn't break the
  > builds.)
I'm more than aware of the advantages that having code in the tree provides,
but the code has to meet a certain level of correctness before it will go in.
No ifs, ands or buts about it.  This is not "throw it over the wall and watch
developers scatter" development, nor is it "wait until it is 100% perfect"
development.  There's a point in-between that we're shooting for.

Dropping it in before it hits that level of correctness is just going to make
everyone life miserable, waiting too late would make gpc suffer.  Finding the
right time to contribute can be difficult, but it's really necessary for the
health of both projects.


jeff