[kaffe] Next development release planning - 1.1.5

[Dalibor Topic]

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 compare&swap 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.