This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Modules names and other details for new classpath bug product
- From: Bryce McKinlay <mckinlay at redhat dot com>
- To: David Daney <ddaney at avtrex dot com>
- Cc: Mark Wielaard <mark at klomp dot org>, classpath at gnu dot org, java at gcc dot gnu dot org
- Date: Mon, 14 Feb 2005 17:32:26 -0500
- Subject: Re: Modules names and other details for new classpath bug product
- References: <1108400078.1701.42.camel@localhost> <4210EDF8.8080705@avtrex.com>
David Daney wrote:
My understanding is that you want to integrate the libgcj and
classpath bug databases with but still maintain the current situation
with the actual code where there are separate code bases.
How would a bug be marked that is fixed in libgcj and not fixed in
classpath?
In general, that shouldn't happen. libgcj developers should be in the
habit of committing such fixes simultaniously to classpath. In the rare
case where for some technical reason a fix can't be committed to the
classpath repository, this could be handled with something like the
reported-against/known-to-work/known-to-fail fields in GCC.
It sounds a bit questionable to merge the bug tracking system before
we have a single merged code base.
I don't think so. The vast majority of the code is merged. The vast
majority of class library bugs are applicable to both libgcj and
classpath. There may be a few issues to overcome, but it will be much
more convenient to have a single combined bug database. For one thing,
if someone does file a bug against libgcj that is really a generic
classpath bug, it should be very easy to "move" the bug upstream just by
re-categorizing it.
Bryce