Re: Modules names and other details for new classpath bug product
> "David" == David Daney <[EMAIL PROTECTED]> writes: David> It sounds a bit questionable to merge the bug tracking system before David> we have a single merged code base. Classpath and libgcj are really like different branches of a single source base. They mostly share code, but some parts are different and they move at different speeds -- I see the situation as being analogous to the difference between the trunk and the gui branch. I think having a shared bug database is basically an administrative move, recognizing that most of these bugs are really shared. We can manage them the way we manage bugs on any branches. There are already a fair number of bugs in the gcc bugzilla that really are classpath bugs... merging like this just makes it simpler to push bugs upstream, and for classpath and gcj hackers to have a shared view of the library's state. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
Hi. Stuart Ballard wrote: Is there a plan for getting them to properly merge? IMHO a difference of only 25 files suggests that it should be perfectly possible for gcj to use an out-of-the-box classpath build and merely prepend a custom jar file containing those 25 files to the beginning of its bootclasspath. I agree that merging the bug databases is a step in the right direction, but I share David's concern about merging the bug databases without actually merging the codebases. If there's some kind of concrete plan as to how a codebase merge is going to be achieved, it might alleviate some of those concerns. The same was proposed by Archie Cobbs but no one answered to this. Considering GNU Classpath the root (of all evil :P ) for all Free Java projects seems like a good idea for me. What speaks against this? cu Robert ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
> "Stuart" == Stuart Ballard <[EMAIL PROTECTED]> writes: Stuart> On Mon, 14 Feb 2005 20:32:38 +0100, Mark Wielaard <[EMAIL PROTECTED]> wrote: >> It is a concern that we have not been able to completely merge libgcj >> and GNU Classpath. Stuart> Is there a plan for getting them to properly merge? IMHO a difference Stuart> of only 25 files suggests that it should be perfectly possible for gcj Stuart> to use an out-of-the-box classpath build and merely prepend a custom Stuart> jar file containing those 25 files to the beginning of its Stuart> bootclasspath. libgcj is weird, so the bootclasspath trick won't actually work for us. But yeah, merging is a pain, and since Michael told us today he wouldn't have much time for it, today on irc we brainstormed a bit and came up with the proposal that Tom Fitzsimmons posted to the gcj list today. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
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 ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
Mark Wielaard wrote: >>This seems like putting the horse before the cart. > > If you have a concrete proposal to help out the active mergers (mostly > Michael Koch for classpath<->libgcj and gui<->classpath, Graydon Hoare > for gui<->libgcj, Andrew Hughes for classpath<->generic and Dalibor > Topic for classpath<->kaffe) then I am sure everybody would be > interested. What about the proposal to just have one source tree (Classpath) for the 95% of the code that's the same, and let libgcj have its 25 files that differ stored separately? Then you compile these class files and ensure they sit before the 'stock' Classpath files in the bootclasspath. By the way, this is what JC does and it works fine. An added advantage is that you can share a Classpath installation among more than one free VM. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com * Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. * ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
Hi, On Mon, 2005-02-14 at 12:24 -0800, David Daney wrote: > Mark Wielaard wrote: > > > If bugs stay fixed on only one code branch we are doing something > > seriously wrong. > > > >>How would a bug be marked that is fixed in libgcj and not fixed in > >>classpath? > > > > That should really not happen. > > It will always happen until someone manually merges. Yes. And that should normally be happing pretty quickly these days. > When I commit changes I only do it for libgcj, I never merge to > classpath. So it *will* happen for any changes I commit. Sure. But that just means the we can assume the bug as closed, since someone will then merge that fix to one of the other tree. See the comparison pages in my last email. Some people even get email from scripts each night with the new diffs between the trees. If you want we can setup a real mailinglist for that. Most people actually have commit access to GNU Classpath and libgcj. I am really not seeing much of a problem with some people just committing to one tree at times. It would be better if GNU Classpath could be seen as the upstream of libgcj, kaffe, etc. and fixes only flowing in one direction. But this isn't the case at the moment, although it is much better then a few years ago. Currently it is just a little annoyance at times. Not something that needs an immediate fix. If only because it is on one hand not that big a problem and on the other hand much harder to fix then merging the bug databases. > > It is a concern that we have not been able to completely merge libgcj > > and GNU Classpath. But merging the bug reporting mechanisms of both is a > > step in the right direction for coordinating bug fixing and keeping the > > code in sync even more. > > This seems like putting the horse before the cart. If you have a concrete proposal to help out the active mergers (mostly Michael Koch for classpath<->libgcj and gui<->classpath, Graydon Hoare for gui<->libgcj, Andrew Hughes for classpath<->generic and Dalibor Topic for classpath<->kaffe) then I am sure everybody would be interested. I personally think that getting more resources (the bug database in this case) in the same place so we are at least getting rid of the bug-mergers (which we don't really have!) is a step in the right direction. Especially since the separate bug reporting is really hurting us at the moment. Wish I could magically make all code bases equal and the same really... Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
On Mon, 14 Feb 2005 20:32:38 +0100, Mark Wielaard <[EMAIL PROTECTED]> wrote: > It is a concern that we have not been able to completely merge libgcj > and GNU Classpath. Is there a plan for getting them to properly merge? IMHO a difference of only 25 files suggests that it should be perfectly possible for gcj to use an out-of-the-box classpath build and merely prepend a custom jar file containing those 25 files to the beginning of its bootclasspath. I agree that merging the bug databases is a step in the right direction, but I share David's concern about merging the bug databases without actually merging the codebases. If there's some kind of concrete plan as to how a codebase merge is going to be achieved, it might alleviate some of those concerns. (I also regularly pester the Kaffe list with a similar question because again, the differences seem so small that it *must* be possible to do something better with Dalibor's time than waste it on constant merging of the other 3175 files) Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
Mark Wielaard wrote: If bugs stay fixed on only one code branch we are doing something seriously wrong. How would a bug be marked that is fixed in libgcj and not fixed in classpath? That should really not happen. It will always happen until someone manually merges. When I commit changes I only do it for libgcj, I never merge to classpath. So it *will* happen for any changes I commit. It sounds a bit questionable to merge the bug tracking system before we have a single merged code base. Perhaps I am misunderstanding what you are recommending. It is a concern that we have not been able to completely merge libgcj and GNU Classpath. But merging the bug reporting mechanisms of both is a step in the right direction for coordinating bug fixing and keeping the code in sync even more. This seems like putting the horse before the cart. Just my $0.02, I will keep quiet now. David Daney. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
Hi, On Mon, 2005-02-14 at 10:29 -0800, 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. Yes, but the code bases are actually not that separate. Fixes in one of the trees are merged within days most of the time. Of the around 3200 files just about 25 are/should be really different. And some of these are different by design. See also the GNU Classpath compare pages that track any differences between the various GNU Classpath branches (generics, kaffe, libgcj, gui). http://developer.classpath.org/compare/ A big THANKS should go to Michael Koch for staying on top of this. He does a hell of a job trying to keep the branches in sync! He would of course like help whenever possible. I am hoping a central bug database where people can see an issue is fixed will help with getting more volunteers merging fixes between the trees regularly. If bugs stay fixed on only one code branch we are doing something seriously wrong. > How would a bug be marked that is fixed in libgcj and not fixed in > classpath? That should really not happen. The proposal is for a bug database that has all the "generic" bugs in the core class library as shared by all runtimes, gcj, kaffe, ikvm.net, etc. There should be a separate module/category in the gcc bugzilla for 'libgcj' runtime issues and runtime specific classes/files. (Just like the other runtimes/compilers would keep their own bug reporting mechanism for non-core-class-library specific bugs.) > It sounds a bit questionable to merge the bug tracking system before we > have a single merged code base. > > Perhaps I am misunderstanding what you are recommending. It is a concern that we have not been able to completely merge libgcj and GNU Classpath. But merging the bug reporting mechanisms of both is a step in the right direction for coordinating bug fixing and keeping the code in sync even more. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
David Daney wrote: How would a bug be marked that is fixed in libgcj and not fixed in classpath? It sounds a bit questionable to merge the bug tracking system before we have a single merged code base. Maybe we shuld treat libgcj and classpath as branches of a common "virtual repository". This does not necessaily mean using the same cvs (or snv) repository, though that is an option. It does mean marking bugs in bugzilla in as *if* they were branches. It would require thinking about naming convention for "target milestones" etc. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
Hi, On Mon, 2005-02-14 at 18:30 +0100, [EMAIL PROTECTED] wrote: > > - Version numbers. > > I don't have a very good suggestion here. Of course we should just > > have the GNU Classpath version numbers there (0.13, 0.14, and up). But > > those are not the same as used by GCC. There is no good/perfect > > mapping between libgcj and classpath version numbers. > > That was my first question; if AWT/Swing bugs are reported for GCJ they > 'should' be mapped to a classpath release, if possible. But I have no idea > how to do that :) There will probably be much more GNU Classpath releases/versions then libgcj versions. We can probably add GCC/libgcj version numbers but only use them in the "Known to fail/Known to work" fields. > > - Move the bugs currently in the savannah bug tracker to > > gcc.gnu.org/bugzilla. [...] I will move at least > > the open ones by hand (currently 59 open bugs). > > My reported bugs will then nog be registred under my email? Should all > classpath bug-reporters (that want to 'keep' their bugs) open an account > on the gcc bugtracker? Just got email from Sylvain Beucler, one of the savannah hackers, and Daniel Berlin, the GCC bugmaster. We will be able to get a sql-script export from the savannah-tracker that we can use to import into bugzilla. So, if all goes well, most attributes of the savannah bugs should be preserved when they are put into gcc bugzilla. GCC bugzilla has a email alias feature as far as I know. So you should be able to alias your bugzilla account/email-address to the one used in the savannah bugtracker (id). I'll explicitly ask about this when we do the actual migration (most probably not before March 1). Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
Mark Wielaard wrote: inetlib, texidoclet, gjdoc, cp-tools, automakejar (Are all these necessary? Maybe just gjdoc and cp-tools?) There will be a new TexiDoclet (rewritten from scratch) soon and it will probably make sense to put it into the same repository as Gjdoc. So I'd say the current TexiDoclet can go in the attic instead. Julian ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
Mark Wielaard wrote: Hi Hackers, Assuming we don't get huge objections to the proposal to move all GNU Classpath bugs to a new gcc bugzilla product we should already start thinking about some details of the new setup. Here is my proposal. . . . Comments? Other suggestions? 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? It sounds a bit questionable to merge the bug tracking system before we have a single merged code base. Perhaps I am misunderstanding what you are recommending. David Daney ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
On Mon, Feb 14, 2005 at 05:54:38PM +0100, Mark Wielaard wrote: > Hi Hackers, Proposal sounds like a good idea! > - Version numbers. > I don't have a very good suggestion here. Of course we should just > have the GNU Classpath version numbers there (0.13, 0.14, and up). But > those are not the same as used by GCC. There is no good/perfect > mapping between libgcj and classpath version numbers. That was my first question; if AWT/Swing bugs are reported for GCJ they 'should' be mapped to a classpath release, if possible. But I have no idea how to do that :) > - Actually moving the bugs. We have two tasks: > - Move the bugs currently filed under gcc/libgcj which are not runtime > specific to the correct classpath/category. This is not that hard, > but needs a volunteer to go over the 110 open bugs in that category. > (The AWT and SWING modules will probably be moved automatically) > - Move the bugs currently in the savannah bug tracker to > gcc.gnu.org/bugzilla. [...] I will move at least > the open ones by hand (currently 59 open bugs). My reported bugs will then nog be registred under my email? Should all classpath bug-reporters (that want to 'keep' their bugs) open an account on the gcc bugtracker? -- Thomas Zander pgpI2rB4HUBFL.pgp Description: PGP signature ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Modules names and other details for new classpath bug product
Hi Hackers, Assuming we don't get huge objections to the proposal to move all GNU Classpath bugs to a new gcc bugzilla product we should already start thinking about some details of the new setup. Here is my proposal. - The product in gcc bugzilla will be called 'classpath'. - I will create a new mailinglist [EMAIL PROTECTED] that will receive all bugzilla activity/emails for the new 'classpath' product. - It seems a good idea to have modules for the main packages. But group them together a bit and not create a module for every (sub)package: accessibility, applet, awt, beans, crypto, imageio, io, lang, reflect, ref, math, naming, net, nio, print, rmi, security, sql, swing, text, transaction, util, jar, logging, prefs, regex, zip, xml. (Note that there is already a SWING and AWT module in gcc, these should be moved to the new classpath product.) Plus modules for the somewhat separate modules: inetlib, texidoclet, gjdoc, cp-tools, automakejar (Are all these necessary? Maybe just gjdoc and cp-tools?) - Version numbers. I don't have a very good suggestion here. Of course we should just have the GNU Classpath version numbers there (0.13, 0.14, and up). But those are not the same as used by GCC. There is no good/perfect mapping between libgcj and classpath version numbers. - Actually moving the bugs. We have two tasks: - Move the bugs currently filed under gcc/libgcj which are not runtime specific to the correct classpath/category. This is not that hard, but needs a volunteer to go over the 110 open bugs in that category. (The AWT and SWING modules will probably be moved automatically) - Move the bugs currently in the savannah bug tracker to gcc.gnu.org/bugzilla. This is harder since we will probably have to move them by hand. I have asked the savannah-hackers whether they can give us an exported database so we might be able to write a script for importing. If that isn't possible I will move at least the open ones by hand (currently 59 open bugs). Comments? Other suggestions? Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
