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: guerby at acm dot org
- Subject: Re: Why not gnat Ada in gcc?
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Wed, 01 Nov 2000 16:55:47 -0700
- cc: kenner at vlsi1 dot ultra dot nyu dot edu, rms at gnu dot org, gcc at gcc dot gnu dot org
- Reply-To: law at redhat dot com
In message <200010141017.MAA01686@ulmo>you write:
> Jeff wrote:
> > From my experience it's a lot easier to deal with the merge policy
> > at the same time you move the bits into the tree since it has major
> > impacts on the development policy.
>
> I for sure do not have your experience on this subject, but from what
> I know about the Ada community right now, this is a non issue for at
> least one year (major changes being made).
>
> May be you have this opinion because you managed "high pressure" or
> multi-contributors projects to go in public CVS for which I agree that
> policy must be set strictly otherwise chaos will occur much to the
> detriment of the GNU community.
It was mostly from watching how development actually worked in both merge
scenarios.
With GCC the policy was the external tree was the master and Cygnus did
merges from the external tree to its internal tree. If folks made changes
to the internal tree, they were responsible for either getting them
into a state suitable for the external tree, or maintaining them for
internal use (with markers to point out local changes). Any difference
between the internal & external trees had to have a marker in the
internal tree or the change was removed when we did merges.
That strongly encouraged development to happen in a more open way on the
external tree with input from external contributors. It also leveled the
playing field a lot for external contributors.
GDB started out the opposite way -- the internal Cygnus tree was the master
and a "sanitization" process would remove local code to produce a "clean"
tree which would then be used to merge into the external tree.
That process did nothing to encourage open development and it was eventually
changed to work like GCC. This was somewhat painful for everyone (internally
and externally).
> Richard Kenner wrote:
> > I think the method of merges that will end up being the most
> > appropriate will strongly depend on the extent of changes being made
> > in the net sources.
>
> Agreed.
I disagree. For the playing field to be level for all GNU Ada developers,
the tree on gcc.gnu.org has to be the master with no bulk merges -- or
all GNU Ada developers have to have the ability to do bulk merges.
Bulk merges are inherently bad for development -- that badness shouldn't
be imposed on the official GNU sources.
jeff