Proposal: eliminate GNU Classpath <-> libgcj merging

Wed Feb 16 01:32:00 GMT 2005

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