Re: Proposal: eliminate GNU Classpath <-> libgcj merging

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Tom" == Thomas Fitzsimmons <fitzsim@redhat.com> writes:

Tom> On IRC today, we discussed ways to eliminate the need for merging
Tom> between GNU Classpath and libgcj.  We came up with this potential
Tom> solution:

A little background here: the deal is, Michael told us on irc that he
wouldn't have much time for merging in the future; there's general
agreement that merging is basically a waste of time anyway; and
finally, Classpath development now goes much more quickly, so merging
takes more and more time.

Tom> - Is the risk of build-breakage increased?

I do think the risk is increased a bit.  Bryce points out a good set
of rules for dealing with this.

We may need to be more careful about testing patches that touch on
native code.  For instance, suppose Classpath has some native-related
rearrangement, then one of us updates and fixes the CNI code to
cope... we'd want to test with an unmodified checkout as well.

I think we should probably supply a merge script to make it as easy as
possible to do these merges.

Tom> - How would this affect casual builders of libgcj?

Assuming GCC does the switch, it's worth considering this use of svn,
where we could specify that the libjava/classpath directory come from
the classpath svn server:

    http://svnbook.red-bean.com/en/1.1/ch07s03.html

Whether this is a good idea, I'm not sure.  I think there are some
drawbacks, for instance what we would do when there is a new gcc
branch.

Tom