Re: Why not gnat Ada in gcc?

[Stan Shebs <shebs at apple dot com>]

Robert Dewar wrote:
> 
> <<You're working on free software for the fsf, therefore IMO you ought
> to be doing your development in the open if at all possible.  And
> clearly (as Cygnus nee Red Hat and Codesourcery demonstrate) it is
> not only possible, but not particularly difficult.
> >>
> 
> Actually from past experiences recently, e.g. with the ia64 port, I have
> been struck by how closed the development was. Same thing for gdb5, this
> was kept under wraps for a long time. A large company (I won't name names)
> that we worked with was essentially operating as though it were under
> non-disclosure. Both the ia64 port and gdb5 were sudden massive updates,
> and it is hard to see how else it could have been done.

The GDB 5 changes were basically the last gasp of the old way of
working on GDB.  Since we didn't think anybody else cared what we
did with GDB internals, the reasoning went that there wasn't much
point in posting a lot of information externally, since the developers
involved were on Cygnus' internal mailing lists, and the discussion
happened there.  In retrospect, it meant that we missed out on input
from other people who've since become valuable contributors to the
open process, so I wouldn't recommend to anybody that they go the
closed way again, at least for general architectural improvements.

For big projects done openly, branches work pretty well.  If you look
at GCC for the past year, there have been a number of efforts that
used a branch while they were incomplete.  There is also the scaffolding
or configure option approach, such as is being done now for the
integrated preprocessor.  

Now having worked large projects both ways, I must say that I can't see
any technical advantages to closed development.  Closed development
should be a disfavored option, only taken in exchange for an explicit
payoff such as funding for a specific improvement or extension.

Stan