Re: [kaffe] Planning for 1.1.3 release
On Fri, 21 Nov 2003 19:50:19 +0100 Dalibor Topic [EMAIL PROTECTED] wrote: Hi Jim, Jim Pick wrote: Hi, It's getting to close to that time again. Isn't having a regular release schedule fun? Yep. I'd actually propose a faster release schedule: once a month after 1.1.3. There is so much changing every two months, that the steps between releases are quite huge, so that people following developer releases instead of CVS may have a harder time reporting bugs based on releases only. I originally hoped to do the developer releases monthly, but I find that it usually takes an entire weekend to get it out, so I'm happier with the two month schedule, just from a personal time commitment perspective. I imagine that when the big merging settles down, it should be less of an issue. This should be the last development release before we get serious about putting together a real production release. Here's the dates I have penciled in for that: Sunday, January 18, 2004 - Feature Freeze for 1.2.0 Sunday, January 23, 2004 - Release Candidate - 1.2.0-rc1 Sunday, February 1, 2004 - Release Candidate - 1.2.0-rc2 Sunday, February 8, 2004 - Release 1.2.0 (Production Release) I'm not so optimistic about a stable release that soon, as I don;t think we should really cut that one based on time passed alone, but also define a list of features we want to see in, as well as platforms we want to see run, applications we want to offically list as supported in 1.2 etc. For example, I think we shouldn't release 1.2 before the switch to GNU Classpath is completed. Okay, I think some release goals would be a great thing to have. On the other hand, I don't want to have 1.0.7 on the website as our production release for too much longer, so I think we should still pick a date. Eighteen months between production releases is already a long time. If we slip on the goals, then we can postpone the release. Since we don't have dedicated developer resources, we've got to be careful that the slippage doesn't get out of hand, or the release will never happen. So we should keep the goals pretty minimal. I believe that a real solid, supported production release would really encourage a lot more people to give Kaffe a try, and to get more involved. A perpetual stream of unsupported developer releases won't do that. Let's postpone setting a date for the production release until after 1.1.3 is out. Maybe we'll do a 1.1.4 development release. We need to have a discussion about what should constitute the release goals for the production release. I think that will be easier once we have some decent documentation that shows where we are. Given the moving target nature of what we are doing, we might want to identify a core set of APIs, ports and features that we support, and mark the rest of the stuff as experimental/unsupported. It would be nice to identify certain applications and certify that certain versions of them work on the Kaffe production release. I'm glad to hear it's actually working for something, browsing the list traffic I sometimes catch myself thinking: how are we ever going to fix all these bugs ... ;) But I guess that's just the effect of kaffe getting better, and more people trying it out where it hasn't been tried out before (or for a long time ;) That's so true... :-) Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Planning for 1.1.3 release
Hi Jim, Jim Pick wrote: Hi, It's getting to close to that time again. Isn't having a regular release schedule fun? Yep. I'd actually propose a faster release schedule: once a month after 1.1.3. There is so much changing every two months, that the steps between releases are quite huge, so that people following developer releases instead of CVS may have a harder time reporting bugs based on releases only. Here are the upcoming dates I'm shooting for: Sunday, November 30, 2003 - Feature Freeze for 1.1.3 Sunday, December 7, 2003 - Release 1.1.3 If I've been somewhat quiet lately, it's mostly because I've had a real nasty cold for the last few weeks, and I've got a few side projects on the go that are eating up my project time. Good to see you're back up again, and beaten the cold. I have been fighting with something nasty in my throat last week myself, but it only hurts when I breathe :) I promised some DocBook documentation, and I haven't done it yet, so that's still the highest thing on my personal priority list. I feel the lack of structured documentation is really holding us back in a lot of ways -- I've got a plan, I just need to make some time to do it. I still need to polish off my regression testing reporting framework as well. It would be nice if you could layout the plan for the DocBook transition, so that we can focus on fixing kaffe to work with the required apps, if possible. This should be the last development release before we get serious about putting together a real production release. Here's the dates I have penciled in for that: Sunday, January 18, 2004 - Feature Freeze for 1.2.0 Sunday, January 23, 2004 - Release Candidate - 1.2.0-rc1 Sunday, February 1, 2004 - Release Candidate - 1.2.0-rc2 Sunday, February 8, 2004 - Release 1.2.0 (Production Release) I'm not so optimistic about a stable release that soon, as I don;t think we should really cut that one based on time passed alone, but also define a list of features we want to see in, as well as platforms we want to see run, applications we want to offically list as supported in 1.2 etc. For example, I think we shouldn't release 1.2 before the switch to GNU Classpath is completed. Now for some wishlist items about the top things I currently care about (feel free to add what I've missed): - Improved documentation - Improved testing - Improved processes for keeping in sync with projects such as Classpath - Enough NIO support to get the latest builds of Freenet and Ant working - More testing and bugfixing on the verifier and security APIs - Make Kaffe work as a Mozilla plugin Aleksandr did some work on this. I have the code, but I didn;t have the time to test it. - Improved profiling and debugging support - Fix the Cygwin port, and Mac OS X port (eg. working PowerPC JIT). If we have decent support for all the major desktop environments, we might win some users over. - Easier support for graphical apps, with the ability to switch between multiple AWTs at run-time, etc. - Merge our fixes back to Classpath (that's what I'm doing now. I don't know if I'll have time for anything else in the next two weeks, since the diff is *huge* and selling all the patches to GNU Classpath developers is hard work. While we tend to spot their bugs fix them, they tend to spot our bad changelogs, lack of tests and comments, and demand that those are fixed first ... and someone has to do it, anyway, as it's quite hard to resync with Classpath without those patches going in one day ;) - Fix the build bugs - Merge in inetlib and jacorb - Man pages for all kaffe executables - Fix supreet's gtk AWT - Pull in new AWT stuff from james/helmer when it's done Looking over the things that I wanted to see done for 1.1.2, I see that half of those are now done ;) The rest: - Getting gjdoc in. - Adding more docs on what third party components are used in kaffe, where they came from, what the licenses are etc in THIRDPARTY - a THIRDPARTY-CHANGES file documenting the changed files with respect to Classpath, for example - merging the outstanding patches in (long mail from michael) - fixing the libtool-vs-static-vm problem pointed out by Kiyo and Andrea - fixing the libtool-vs-cross-compilation problem pointed out by sebastian - fixing the long standing broken strtod replacement issue for Linux 2.0 Longer term things to do: - Get GL4Java to work - Ask Jean Daniel Fakete about license change to Agile2D to be able to include it in kaffe. I'm pretty amazed by how far Kaffe has come in just the last few months. I use it everyday now (primarily for webapps), and I'm very happy about that. I'm glad to hear it's actually working for something, browsing the list traffic I sometimes catch myself thinking: how are we ever going to fix all these bugs ... ;) But I guess that's just the effect of kaffe getting better, and more people trying it out where it hasn't been tried out before (or for a long time ;) cheers, dalibor topic
Re: [kaffe] Planning for 1.1.3 release
I'm not so optimistic about a stable release that soon, as I don't think
we should really cut that one based on time passed alone, but also
define a list of features we want to see in, as well as platforms we
want to see run, applications we want to offically list as supported in
1.2 etc. For example, I think we shouldn't release 1.2 before the switch
to GNU Classpath is completed.
That could be a awhile to use all of Classpath. I have alot of work to do
for the AWT porting. I'm working on the native code right now which
required a rewrite.
- Easier support for graphical apps, with the ability to switch between
multiple AWTs at run-time, etc.
I was thinking about how to do that. We might be able to attach a Toolkit
to a GraphicsConfiguration. I will have to think about it.
- Pull in new AWT stuff from james/helmer when it's done
I started to working on the Frame and Window peers but I was missing to
much info. At present I'm working on the the Grpahics*.java files in
java/awt. I wrote a test apps and ran it against the SUN JVM. So now to
implement it against Kaffe.
import java.awt.image.*;
import java.awt.*;
class Screen
{
GraphicsEnvironment ge;
GraphicsDevice active;
GraphicsDevice[] gs;
public static void main(String args[])
{
Screen screen = new Screen();
screen.GetSizeOfAllScreens();
screen.Configure();
}
Screen()
{
ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
gs = ge.getScreenDevices();
active = ge.getDefaultScreenDevice();
}
public void Configure()
{
GraphicsConfiguration[] configs = active.getConfigurations();
GraphicsConfiguration current = active.getDefaultConfiguration();
for (int i = 0; i configs.length; i++) {
Rectangle box = configs[i].getBounds();
System.err.println(Width +box.getWidth()+ Height
+box.getHeight());
ColorModel colors = configs[i].getColorModel();
System.err.println(Color model is +colors.toString());
BufferCapabilities buffer = configs[i].getBufferCapabilities();
System.err.println(Back buffer support is
+buffer.isMultiBufferAvailable());
System.err.println(Full screen is need?
+buffer.isFullScreenRequired());
ImageCapabilities imagedata =
configs[i].getImageCapabilities();
System.err.println(Image accelerated support?
+imagedata.isAccelerated());
}
}
public void GetSizeOfAllScreens()
{
// Get size of each screen
for (int i = 0; i gs.length; i++) {
System.err.println(gs[i].getIDstring());
System.err.println(gs[i].getType());
System.err.println(Available Accelerated memory is
+gs[i].getAvailableAcceleratedMemory());
if (gs[i].isDisplayChangeSupported() == true)
System.err.println(Display can change size);
else
System.err.println(Display can't change size);
if (gs[i].isFullScreenSupported() == true)
System.err.println(Full Screen Support);
else
System.err.println(No Full Screen Support);
DisplayMode[] dm = gs[i].getDisplayModes();
for (int j = 0; j dm.length; j++) {
int screenWidth = dm[j].getWidth();
int screenHeight = dm[j].getHeight();
System.err.println(Screen width is +screenWidth+
and height is +screenHeight+ of Display +i);
}
}
}
}
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Planning for 1.1.3 release
Hi, It's getting to close to that time again. Isn't having a regular release schedule fun? Here are the upcoming dates I'm shooting for: Sunday, November 30, 2003 - Feature Freeze for 1.1.3 Sunday, December 7, 2003 - Release 1.1.3 If I've been somewhat quiet lately, it's mostly because I've had a real nasty cold for the last few weeks, and I've got a few side projects on the go that are eating up my project time. I promised some DocBook documentation, and I haven't done it yet, so that's still the highest thing on my personal priority list. I feel the lack of structured documentation is really holding us back in a lot of ways -- I've got a plan, I just need to make some time to do it. I still need to polish off my regression testing reporting framework as well. If anybody else has some goals for this release, please follow up to this email. This should be the last development release before we get serious about putting together a real production release. Here's the dates I have penciled in for that: Sunday, January 18, 2004 - Feature Freeze for 1.2.0 Sunday, January 23, 2004 - Release Candidate - 1.2.0-rc1 Sunday, February 1, 2004 - Release Candidate - 1.2.0-rc2 Sunday, February 8, 2004 - Release 1.2.0 (Production Release) Now for some wishlist items about the top things I currently care about (feel free to add what I've missed): - Improved documentation - Improved testing - Improved processes for keeping in sync with projects such as Classpath - Enough NIO support to get the latest builds of Freenet and Ant working - More testing and bugfixing on the verifier and security APIs - Make Kaffe work as a Mozilla plugin - Improved profiling and debugging support - Fix the Cygwin port, and Mac OS X port (eg. working PowerPC JIT). If we have decent support for all the major desktop environments, we might win some users over. - Easier support for graphical apps, with the ability to switch between multiple AWTs at run-time, etc. Again, these are wishlist items, so I'm not making any promises that we will deliver these. But I'm definitely willing to throw in some of my own time to help drive these forward. I'd be really happy even if we just make a small bit of progress on these items. Sun will kick out Java 1.5 in the Spring, I think, so we'll be playing catch up once again. But it would be nice to have a really solid production release in the Spring that we would be happy to say we support. I'm pretty amazed by how far Kaffe has come in just the last few months. I use it everyday now (primarily for webapps), and I'm very happy about that. Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
