Merging GNU Classpath and gcc/libgcj bug databases

[Mark Wielaard <mark at klomp dot org>]

Hi GCC and GNU Classpath and libgcj hackers,

This is a request for comments on moving the GNU Classpath bug reports
(currently on savannah.gnu.org) into the gcc bugzilla database (as a
separate project). This will ease sharing information between the GNU
Classpath and GCC/GCJ hackers.

We have discussed the impact of this with Daniel Berlin and the rest of
the GCC Bugmasters who don't see any technical or maintenance problems
with this. It would solve an important problem for the GNU Classpath and
gcj hackers who are now relying on two different bug databases without
an easy way to move bugs between them.

If there are no objections we would like to close down the savannah bug
tracker for GNU Classpath and add a new "product" classpath in GCC
bugzilla which contains all the current bug reports. This new
'classpath' product shall be used exclusively in the future for all core
library bug reports in either GNU Classpath or libgcj as long as they
are "generic" bugs. The libgcj component in the gcc bugzilla product
would still be used for bugs in the runtime, as distinct from the class
libraries (ie classpath), and for bugs in the few GCJ-specific classes
that still exist.

I will send a proposal for the module names, standard bug mailinglist
and version numbers to use for this new classpath product in the
database to the classpath and libgcj development mailinglists soon. The
current gcc modules AWT and SWING would also move to this new product.
Which should help with the issue that gcc bugzilla product currently has
a lot of modules already.

Some background information. GNU Classpath core class library has been
mostly merged with libgcj for a couple of years now. The main technical
difference between them is that libgcj is tightly integrated with the
actual gcj/libffi/boehmgc runtime from GCC and GNU Classpath is
explicitly kept "execution mechanism neutral". There are about 20 other
runtimes and/or compilers based on GNU Classpath next to gcj. Although
gcj is probably the most widely distributed one. And the "official GNU
supported" one. The FSF sees libgcj and classpath as "merged". And
paperwork for libgcj and GNU Classpath is handled in the same way (like
the rest of GCC).

GNU Classpath is hosted on http://www.gnu.org/software/classpath/ for
the public webpages and uses savannah.gnu.org most developer resources
(cvs, mailinglists). We have a separate development machine
developer.classpath.org for dynamic content, scripts, and developer
wikis, etc and http://planet.classpath.org/ for blog aggregation of the
various GNU Classpath (and related project) hackers. GCC is mainly
hosted on one machine gcc.gnu.org with their own cvs, wiki, mailinglists
and bugzilla database separate from the savannah.gnu.org bugtracker.

GNU Classpath is maturing and provides a serious free alternative to the
proprietary core libraries for the java programming language. And gcj
has been made a solid member of the GNU Compiler Collective that is
actively being used by more and more people. We are now getting
bugreports through different channels. Having multiple bug databases
against which users report bugs is causing serious problems since
monitoring the different bug databases and moving bugs between them is
not trivial. The upcomming GCC 4.0 will have a gcj mature enough to
support large free software projects written in the java programming
language like Eclipse, lots of the Apache projects and java-gnome
applications. So we are expecting a lot of new bug reports for classpath
to be reported through the gcc bugdatase. So sharing the bug database
architecture/backend with the GCC project makes a lot of sense. By
having it as a separate project we hope to also facilitate the other
free compilers and runtimes based on GNU Classpath.

Cheers,

Mark Wielaard
GNU Classpath Maintainer

Attachment: signature.asc
Description: This is a digitally signed message part