Re: [kaffe] Next development release planning - 1.1.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arnaud Vandyck [EMAIL PROTECTED] writes: Dalibor Topic [EMAIL PROTECTED] writes: F Merge in gjdoc + libxmlj (me, I guess) I'll try to work on gnu jaxp this week (merge with libxmlj) Done. Dalibor has a pre-release. I'll make it more official after the week-end. Cheers, - -- ~/.signature not found doogie asuffield: how do you think dpkg was originally written? :| asuffield by letting iwj get dangerously near a computer -- in #debian-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAeHTm4vzFZu62tMIRApgWAJ44elSM7ypEgzBph8j5U1KPyTTQnACfexwY LbkihO71QkHSYcmrKKMFLL4= =sTOV -END PGP SIGNATURE- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Next development release planning - 1.1.5
Dalibor Topic wrote: Salut Remy, Remy Maucherat wrote: I've always had trouble building on Cygwin. Since I sort of understood this was a supported platform, am I doing soemthing wrong ? (or is a fix in sight for this release ?) It's in 'known-to-be-broken-but-we-can't-du-much-about-it' state. :( Currently we are waiting for a bug in Cygwin to be fixed [1] and signal handlers to be added to it [2]. cgf has been working on adding signal handler support in recent cygwin versions, so there might have been some progress in this area. That's what I though. So I'll have to wait a bit more for testing. BTW, are there any plans for a Kaffe compatible logo and program ? (I could likely add that to the Tomcat front page - once it actually runs 100% out of the box, of course ;) ). Rémy ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Next development release planning - 1.1.5
Salut Remy, Remy Maucherat wrote: I've always had trouble building on Cygwin. Since I sort of understood this was a supported platform, am I doing soemthing wrong ? (or is a fix in sight for this release ?) It's in 'known-to-be-broken-but-we-can't-du-much-about-it' state. :( Currently we are waiting for a bug in Cygwin to be fixed [1] and signal handlers to be added to it [2]. cgf has been working on adding signal handler support in recent cygwin versions, so there might have been some progress in this area. cheers, dalibor topic [1] http://article.gmane.org/gmane.os.cygwin/42015/match=cygwin+dalibor+kaffe [2] http://article.gmane.org/gmane.comp.java.vm.kaffe.general/2826/match=cygwin+signal+guilhem+kaffe ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Next development release planning - 1.1.5
Dalibor Topic [EMAIL PROTECTED] writes: F Merge in gjdoc + libxmlj (me, I guess) I'll try to work on gnu jaxp this week (merge with libxmlj) Cheers, -- ~/.signature not found doogie asuffield: how do you think dpkg was originally written? :| asuffield by letting iwj get dangerously near a computer -- in #debian-devel ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Next development release planning - 1.1.5
Hi, It's been about 2 months since the last development release - I'd like to do another one. I know some people would prefer to see a goal-based development release schedule, as opposed to just releasing every two months. I'm somewhat biased against that, though, just because it's more work for me, and I think the schedule would slip. If we did that, I'd have to switch to a mode where we actually planned and scheduled what was going in, and try to drive development to meet deadline. That might be a good idea, but it's more work, and it's hard to push free software volunteers to meet hard deadlines. Maybe we can do a little bit more of that while still doing timed releases? That might be possible if somebody wants to step forward and volunteer to do some project management. We need to do a production release sometime, the sooner the better, in my opinion. I haven't formulated a concrete plan for that one yet, though. So here's my proposal: How about if we do a feature freeze in three weeks, on Sunday, April 25th, to be followed by an actual release on Sunday, May 2nd? (I'd really like to do it a week earlier, but my parents are coming for a visit) Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Next development release planning - 1.1.5
Jim Pick wrote: Hi, It's been about 2 months since the last development release - I'd like to do another one. I know some people would prefer to see a goal-based development release schedule, as opposed to just releasing every two months. I'm somewhat biased against that, though, just because it's more work for me, and I think the schedule would slip. If we did that, I'd have to switch to a mode where we actually planned and scheduled what was going in, and try to drive development to meet deadline. That might be a good idea, but it's more work, and it's hard to push free software volunteers to meet hard deadlines. Maybe we can do a little bit more of that while still doing timed releases? That might be possible if somebody wants to step forward and volunteer to do some project management. We need to do a production release sometime, the sooner the better, in my opinion. I haven't formulated a concrete plan for that one yet, though. So here's my proposal: How about if we do a feature freeze in three weeks, on Sunday, April 25th, to be followed by an actual release on Sunday, May 2nd? (I'd really like to do it a week earlier, but my parents are coming for a visit) I've always had trouble building on Cygwin. Since I sort of understood this was a supported platform, am I doing soemthing wrong ? (or is a fix in sight for this release ?) Thanks, Rémy ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Next development release planning - 1.1.5
Jim Pick wrote: Hi, It's been about 2 months since the last development release - I'd like to do another one. I know some people would prefer to see a goal-based development release schedule, as opposed to just releasing every two months. I'm somewhat biased against that, though, just because it's more work for me, and I think the schedule would slip. If we did that, I'd have to switch to a mode where we actually planned and scheduled what was going in, and try to drive development to meet deadline. That might be a good idea, but it's more work, and it's hard to push free software volunteers to meet hard deadlines. Maybe we can do a little bit more of that while still doing timed releases? That might be possible if somebody wants to step forward and volunteer to do some project management. We need to do a production release sometime, the sooner the better, in my opinion. I haven't formulated a concrete plan for that one yet, though. So here's my proposal: How about if we do a feature freeze in three weeks, on Sunday, April 25th, to be followed by an actual release on Sunday, May 2nd? (I'd really like to do it a week earlier, but my parents are coming for a visit) Fine for me. As usual, the rundown list of things I'd love to see go into 1.1.5: A Clean up all the warnings (everyone, please :) B Switch remaining platforms to use compareswap from glibc (me) C Switch over to use AutoGen [1] for option parsing (me) D Add -bootclasspath options due to popular request (me) E Merge in Classpath's AWT and pocketlinux implementations (me [2]) F Merge in gjdoc + libxmlj (me, I guess) G Merge in SwingWT (?) H Merge in JACORB (?) I Fix remaining platform-specific failures (riccardo :) J Switch over to Classpath's java.security K Merge in jit4 from mike chen [3] L After the switch to classpath's AWT, merge in gcjwebplugin M Merge in Odonata from Stephane N Merge in PJA O Write the missing man pages that's from the top of my head, right now. cheers, dalibor topic [1] http://www.gnu.org/software/autogen/ [2] Well, once we have -bootclasspath and -bootlibrarypath, we could *in theory* let the user pick an AWT implemenation and switch to it at runtime. I propose to switch over to GNU Classpath's AWT for the java/awt classes (it's actually being heavily developped atm, and is the nicer code base to work with). Then, in another pass, Kaffe's current AWT implementation(s) could be compiled, as well as PocketLinux one(s), and the user could switch the backend via a simple '-awt=something' option. That's the theory, at least. [3] The discussion somehow petered out without a conclusion. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
