This is the mail archive of the
mailing list for the Java project.
Re: Policy on classpath remerges?
- From: Tom Tromey <tromey at redhat dot com>
- To: neroden at twcny dot rr dot com (Nathanael Nerode)
- Cc: java-patches at gcc dot gnu dot org
- Date: 16 Jan 2004 10:43:37 -0700
- Subject: Re: Policy on classpath remerges?
- References: <20040115153031.GA5036@twcny.rr.com>
- Reply-to: tromey at redhat dot com
>>>>> "Nathanael" == Nathanael Nerode <email@example.com> writes:
Nathanael> I seem to remember some special customs for Classpath
Nathanael> remerges. What were they?
Nathanael> I assume remerges still need explicit approval... or are
Nathanael> they sometimes "obvious"?
Some changes can be obvious, especially things like javadoc
improvements. Most changes do need approval however.
Some divergences from classpath are intentional. Most of these are
marked "GCJ LOCAL" -- probably some are not, but all should be. One
known major divergence is java.util.zip -- we have a zlib-based native
implementation (of the compression bits) but Classpath has a pure Java
In theory our nightly comparison knows what divergences are
intentional and flags them in the comparison page. That doesn't quite
seem to be working properly, I'll try to fix it soon.
Nathanael> There was something about ChangeLog entries. Am I supposed
Nathanael> to put the upstream ChangeLog entries into the libjava
Nathanael> ChangeLog? Or was it something else?
Yes, we prefer to keep the same ChangeLog entry when feasible. We've
found this makes it easier to track changes back to their source.
Nathanael> Sorry to be so confused.
It's not your fault, we haven't documented this properly.