On Sun, Jan 19, 2003 at 10:22:23PM +0100, Grzegorz B. Prokopski wrote: > Hi!
Hi again. > <I am starting from scratch because our mails are getting too long> > > I know you're the person who maitains java-common, Java Policy > and I really admire your work you do in that area. Thanks a lot! I appriciate it. > In my initial mail I already proposed that "not meeting the criteria" > is just a bug, maybe even RC in some cases. Hmm ... I thought you objected that it can be RC. If so then we are telling the same things but in different ways. :) > I don't know what 99% or what 80% is. Fact is that aside of Kaffe, > the other free JVMs use indirectly (like gcj) or directly one single > source of it's classpath lisbrary - GNU Classpath. I really doubt if this > project has reached 80% of what java 1.2 (especially in the area of > graphical interfaces) should be. I think that *I* would use GNU > Classpath as the 100% here (then we can have JVMs that support more > than 100% ;-). But I don't really expect you to write it down to > the policy. Hmm. It it that bad. I was not aware of that actually. In some way we have to define java1-runtime in a good way. Define it against a moving target (like classpath) might not be a good thing. On the other hand it might be the best way... > About SableVM - I can only say that currently SableVM is not able to use > all of the features of GNU Classpath. But OTOH I am sure it will get > better. It's being worked on. And I forgot to tell that I admire everyone that are working to make a free alternative. I'm sure it will be better. > But getting back to the topic. > You can treat my mail as an objection because it's still not really > clear what the proposed change in Java Policy would gain us. Ok. It is a good point. > It's still vague. It seem to need more detailed description or no > changes at all. I'd agree to discuss it... probably on d-java? - yes. Let's continue on debian-java, then. > As for my proposals, I think I'd do it this way: > 1. Define exactly what requirements must be met for JVM to be able > to _legally_ provide java-virtual-machine, java*-runtime etc. Then we can agree on that. The problem is to define it... :( > 2. Just file bugs on JVM when the program you want to run - doesn't > work. As usual. Nothing new. The bug will either get fixed or not. No nothing new. > The only question is whether it's RC (or a set of bugs can be > treated as RC) or not. That's sth. we *could* clarify. Yes that has to be clarified. > One question that is bugging me all the time and I am really curious > what's the correct answer: > > Do we actually have a problem? Good question! :) > Will having exact policy in this area gain us anything? Yes I actually think so. The thing we gain is that users can be less confused. If they apt-get things, they tend to think that things should work. If they by (mistake?) got another virtual-machine for their java app they can be pretty disapointed. I become that from time to time... :) This gain nothing to us, but something to the end user. > (Read: Do we rally want our free JVMs to be either kept out of testing > or kept w/o Provides: that can bring them to real live in many uses?) Well actually I do not think it is a good thing to release with a provides line that is not really functional. But I can also accept the other posistion, that says that this is better than non-free alternatives. I agree on both and I'm no longer so sure about this. What do other people think about this issue? Best regards, // Ola > Regards > > Grzegorz B. Prokopski > > PS: I'll wait to see what other have to say on that topic. > > -- > Grzegorz B. Prokopski <[EMAIL PROTECTED]> > Debian http://www.debian.org/ -- --------------------- Ola Lundqvist --------------------------- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---------------------------------------------------------------
