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
signature.asc
Description: This is a digitally signed message part
