Re: Planning for next release (1.0.7)
On Thu, 21 Mar 2002, Dalibor Topic wrote: * i64 platform patch from mandrake. Has cool new feature written all over it and the developer announced it on the mailing list a couple of months ago. Talking about that, it would be interesting to have Kaffe's lib directory be $(libdir)/kaffe/Khost_cpu/ instead of $(libdir)/kaffe/ as it is currently the case. That way, the -ia32 feature (to run the ia32 version of kaffe) could work out of the box without having the distributor to mess with overriding that variable. ;-) Random thoughts: 1) Could someone with an Alpha please try the JIT compiler? It doesn't appear to work according to what someone reported to me. 2) Is release date still expected within one week from now? I wonder if it wouldn't be better to have some public beta or prerelease snapshot first. That way, a wider audience could try it out, I hope. Bye, Gwenole.
Edouard G. Parmelan (Re: Planning for next release (1.0.7))
From: Jim Pick [EMAIL PROTECTED] Subject: Planning for next release (1.0.7) Date: Thu, 21 Mar 2002 07:04:32 -0800 Finally, when we decide to do this release, I think we should dedicate it to the memory of Edouard Parmelan. For those that don't know, he was one of the most active Kaffe developers, a member of the core team, and one of the driving forces behind the project. He died tragically in a motorcycle accident last year, leaving behind a wife and kids. I haven't known that until read Jim's post and I was very surprised. EPG took some of my patches and gave comments when I tried to use jakarta products such as tomcat and ant with kaffe. I really regret him though I haven't met him. I'm fully agree your idea, Jim. All of kaffe users should know him. He also had been contributing for a lot of project other than kaffe. We can find some of his works at following URL: http://egp.free.fr/ He was great. Takashi Okamoto
Re: Planning for next release (1.0.7)
On Thu, Mar 21, 2002 at 07:04:32AM -0800, Jim Pick wrote: Finally, when we decide to do this release, I think we should dedicate it to the memory of Edouard Parmelan. For those that don't know, he was one of the most active Kaffe developers, a member of the core team, and one of the driving forces behind the project. He died tragically in a motorcycle accident last year, leaving behind a wife and kids. I didn't know, I'm shocked :-( What a waste, I'm very sad ! I fully support dedicating that version to the memory of Edouard Daniel -- Daniel Veillard | Red Hat Network http://redhat.com/products/network/ [EMAIL PROTECTED] | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
RE: Planning for next release (1.0.7)
I'm so sad (and shocked) to hear this news. I was having lots of email exchange with Edouard and all of a sudden I couldn't get any response from him. We were trying to port Kaffe to PowerPC/NetBSD, I was impressed by his computer skills and his work attitude. Great idea of dedicating the new version of Kaffe to the memory of Edouard. Allegro Networks Yong Chen -Original Message- From: Daniel Veillard [mailto:[EMAIL PROTECTED]] Sent: Friday, March 22, 2002 3:51 AM To: [EMAIL PROTECTED] Subject: Re: Planning for next release (1.0.7) On Thu, Mar 21, 2002 at 07:04:32AM -0800, Jim Pick wrote: Finally, when we decide to do this release, I think we should dedicate it to the memory of Edouard Parmelan. For those that don't know, he was one of the most active Kaffe developers, a member of the core team, and one of the driving forces behind the project. He died tragically in a motorcycle accident last year, leaving behind a wife and kids. I didn't know, I'm shocked :-( What a waste, I'm very sad ! I fully support dedicating that version to the memory of Edouard Daniel -- Daniel Veillard | Red Hat Network http://redhat.com/products/network/ [EMAIL PROTECTED] | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: Planning for next release (1.0.7)
On Thu, 21 Mar 2002, Jim Pick wrote: It doesn't have to work on everything, but if it doesn't work on a particular platform - it would be nice to identify that in the release notes. What about IA-64 ? I had a patch against some 1.0.6 cvs snapshot 2001/08/19. However, it requires gcc3.0 and there is no JIT support. I heard Debian people would be interested too. Bye, Gwenole.
Re: Planning for next release (1.0.7)
On Thu, 2002-03-21 at 08:44, Mason Loring Bliss wrote: On Thu, Mar 21, 2002 at 07:04:32AM -0800, Jim Pick wrote: For future releases, I'd like to propose a version numbering scheme similar to what's used for the Linux kernel. Out of curiosity, what is gained by that? It seems somewhat arbitrary, as the Linux kernel does it. I'm mostly in favour of the way NetBSD does things, FWIW. Release periodically, branching at each release, and simply dump new features into the trunk. I've done some NetBSD stuff too. It's very CVS-centric though - personally, I like being able to stick a version number on a development-only release and make a tarball. With tarballs, we'll get more testers if people don't feel like they have to continually check out HEAD from cvs all the time. I'm probably just biased because I'm more from a Linux background (Debian, Kernel.org) than a *BSD background. :-) I'm also in favour of frequent releases, however, so that folks wanting the stability of running a release branch never get too horribly far behind. This is not an area where NetBSD shines, but there's no reason why Kaffe can't do it. When we're in full swing development mode, I'd like to see releases made every few weeks or so. Is development active enough to warrant this? Unless there's a crazy amount of development going on, I'd think that doing nothing more frequent than one release per two months would be a sane minimum span of time. The goal, I expect, is to get folks to use Kaffe and start integrating it into their work, and having to update more than a few times per year will become per- nicious, I expect, when what people most want is a stable platform on which to base their Java projects. With sufficient change, and with a tradition of quality and stability, of course, updates can come more frequently without making the user base too nervous. It would of course be cool to see Kaffe rapidly catch up with Java 1.4, for instance. The frequency of the unstable releases would probably depend on whether there is enough changing to warrant it. I've got a lot of ideas, and I'm going to have time to work on it (partly on Transvirtual time), plus I want to suck in quite a bit more 3rd-party stuff, plus other people will be contributing, and the project will be more open - so I suspect that there will be a lot more changes. The stable releases will probably be a lot less frequent - just a major new stable release after each development cycle, plus occasional bug fixes. Fortunately, we're just reimplementing somebody's else's API (Sun), so we don't have to worry so much about release-to-release compatibility of APIs (except for the ones we define). Anyway, take all this with a grain of salt. I'm new to Java, and I don't have commit access to the repository, so I can be safely ignored. :P Thanks for the feedback! Cheers, - Jim
Re: Planning for next release (1.0.7)
Hi Jim, On Thursday, 21. March 2002 16:04, Jim Pick wrote: 1) Solicit feedback on what should be in the release * A recompiled Klasses.jar that works. * An updated kaffe/kaffevm/inflate.c if it suffers from the zlib security bug. * Small obvious patches from distribution vendors. * i64 platform patch from mandrake. Has cool new feature written all over it and the developer announced it on the mailing list a couple of months ago. - what not: * java.security implementation from JanosVM. It is a major enhancement that should not just be rushed in. Leave something for 1.0.8 in 2-3 months :) * s390 platform patch from debian. It is apparently broken. For future releases, I'd like to propose a version numbering scheme similar to what's used for the Linux kernel. eg. Even minor version numbers = I thought if you're downloading straight from CVS you were on the bleeding edge anyway :) Version numbers are just multisets with semantics for me. That being said, we could use the Linux version numbering scheme, if there is a) interest in maintaining an actively developing stable branch, or b) a lot of experimental development ahead. I am not sure if the number of developers is big enough to support parallel development on two trees. But if/when we fold in changes from JanosVM pocketlinix etc. there will be a lot of experimental development. Currently many users (i.e. people who are not developing for/with kaffe) seem to use the CVS version, since 1.0.6 is way behind what's in CVS now. If we release early, often remain stable, then those users will probably switch back to using releases, without being intimidated by the varying degree of stability in the CVS version. In that case, there would be no real need for a specific development branch. But then, it's a big IF, so having a specific bleeding edge development branch might be useful anyway. Count this answer as undecided, but supportive :) dalibor topic P.S. Dedicating a release to Edouard is a very good idea. _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: Planning for next release (1.0.7)
Hello all From: Jim Pick [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Planning for next release (1.0.7) Date: Thu, 21 Mar 2002 07:04:32 -0800 ...snip... Here's how I'm thinking of doing it: 1) Solicit feedback on what should be in the release 2) If there isn't anything major that needs to be done, we'll tag a release candidate for testing in CVS, next week 3) The people on the mailing list will test it for a week (from out of CVS) What would the testing involve? I'd be happy to help if I can. Finally, when we decide to do this release, I think we should dedicate it to the memory of Edouard Parmelan. For those that don't know, he was one of the most active Kaffe developers, a member of the core team, and one of the driving forces behind the project. He died tragically in a motorcycle accident last year, leaving behind a wife and kids. This sounds like a fine idea. I'm all for it. I think the releasing versioning proposals are good. More importantly, I'd like to see the versioning method documented on the website and descriptions of the releases placed in CVS. Mark _ Send and receive Hotmail on your mobile device: http://mobile.msn.com
Re: Planning for next release (1.0.7)
Hi Gwenole, On Thursday, 21. March 2002 18:15, Gwenole Beauchesne wrote: What about IA-64 ? I had a patch against some 1.0.6 cvs snapshot 2001/08/19. However, it requires gcc3.0 and there is no JIT support. I heard Debian people would be interested too. I checked out your patch from mandrake's kaffe-1.0.6-11mdk source distribution. It seems to apply cleanly against the current version from CVS. Could you give that a try, and tell us if it still works? thanks in advance from someone still stuck with ia32 :) dalibor topic _ Do You Yahoo!? Get your free yahoo.com address at http://mail.yahoo.com
Re: Planning for next release (1.0.7)
Hi Friends, I am bit new to open source development. Can somebody take time to highlight how things work in Open Source World and I would be grateful if some details on the process used to compile and test the VM before release. some questions that come up in mind is - Using jikes for getting Kaffee.jar... Why?? - How do we test the VM for conformance?? I guess let me hold to my questions and see if they get resolved as we move along. Regards, Partha - Attitude Matters Parthasarathy G Technology Development Center - HomeNet Wipro Technologies, EI 53/1 , Hosur Road, Madiwala Phone: 91-80-5502001-008 x3130 Fax No: 5502160 Bangalore - 560 068. Visit Home Networks Website * Intranet: http://gruha.wipro.com * Internet: http://www.wipro.com/homenet/ - Original Message - From: Jim Pick [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 21, 2002 8:34 PM Subject: Planning for next release (1.0.7) Hi, Sorry I've been a bit quiet the last few days - things are a bit hectic at Transvirtual as I try to get stuff prepared for JavaOne next week (plus I'm going skiing in Tahoe this weekend). I'd really like to get a new release of kaffe out sometime soon, since it's been too long since the last release (July 24, 2000). I'm not as familiar with the codebase yet as I'd like to be - so I'm asking for opinions on what absolutely should be in the next release. I think the emphasis on this release should be just getting something out that works. It doesn't have to work on everything, but if it doesn't work on a particular platform - it would be nice to identify that in the release notes. Here's how I'm thinking of doing it: 1) Solicit feedback on what should be in the release 2) If there isn't anything major that needs to be done, we'll tag a release candidate for testing in CVS, next week 3) The people on the mailing list will test it for a week (from out of CVS) 4) Two weeks from now, we'll release it as 1.0.7 Does this sound OK? I'm a big believer in release early, release often. For future releases, I'd like to propose a version numbering scheme similar to what's used for the Linux kernel. eg. Even minor version numbers = stable, Odd minor version numbers = unstable. So, future releases in the 1.0.x series would be considered stable, ready for production. We'd open up development on a new 1.1.x series, which ultimately would become 1.2.x when it's deemed ready for a stable release. With this arrangement, as developers, we'll have the freedom to do some radical stuff to the 1.1.x tree, as people downloading it will understand that it's a development series of releases. When we're in full swing development mode, I'd like to see releases made every few weeks or so. What do people think of that idea for versioning and making releases? Finally, when we decide to do this release, I think we should dedicate it to the memory of Edouard Parmelan. For those that don't know, he was one of the most active Kaffe developers, a member of the core team, and one of the driving forces behind the project. He died tragically in a motorcycle accident last year, leaving behind a wife and kids. I'm going to be very busy this coming week with JavaOne next week, but I'll try to stay as involved as possible in trying to make this release happen. Cheers, - Jim **Disclaimer Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited.
