| From | Sent On | Attachments |
|---|---|---|
| Greg Lewis | Jul 8, 2002 8:12 am | |
| Bill Huey | Jul 10, 2002 3:10 am | |
| K.J....@kpn.com | Jul 10, 2002 3:16 am | |
| Bill Huey | Jul 10, 2002 3:28 am | |
| Massimo Lusetti | Jul 10, 2002 3:40 am | |
| Bill Huey | Jul 10, 2002 3:44 am | |
| Marc Recht | Jul 10, 2002 3:44 am | |
| Bill Huey | Jul 10, 2002 4:04 am | |
| Bill Huey | Jul 10, 2002 5:20 am | |
| Georg-W. Koltermann | Jul 10, 2002 1:40 pm | |
| Bill Huey | Jul 10, 2002 4:24 pm | |
| Nate Williams | Jul 10, 2002 4:29 pm | |
| Bill Huey | Jul 10, 2002 4:43 pm | |
| Nate Williams | Jul 10, 2002 4:45 pm | |
| Bill Huey | Jul 10, 2002 4:47 pm | |
| Bill Huey | Jul 10, 2002 4:58 pm | |
| Michael Gratton | Jul 10, 2002 5:17 pm | |
| Bill Huey | Jul 10, 2002 5:33 pm | |
| Michael Gratton | Jul 10, 2002 5:43 pm | |
| Nate Williams | Jul 10, 2002 8:30 pm | |
| Nate Williams | Jul 10, 2002 8:33 pm | |
| Bill Huey | Jul 10, 2002 8:51 pm | |
| Nate Williams | Jul 10, 2002 8:57 pm | |
| Bill Huey | Jul 10, 2002 9:45 pm | |
| Nate Williams | Jul 10, 2002 9:48 pm | |
| Bill Huey | Jul 10, 2002 9:56 pm | |
| Nate Williams | Jul 10, 2002 9:58 pm | |
| Bill Huey | Jul 10, 2002 10:11 pm | |
| Chris Doherty | Jul 10, 2002 11:36 pm | |
| Bill Huey | Jul 10, 2002 11:43 pm | |
| Marc Recht | Jul 11, 2002 4:07 am | |
| Bill Huey | Jul 11, 2002 4:17 am | |
| Marc Recht | Jul 11, 2002 5:08 am | |
| Bill Huey | Jul 11, 2002 7:21 am | |
| Bill Huey | Jul 11, 2002 7:53 am | |
| Marc Recht | Jul 11, 2002 8:04 am | |
| Bill Huey | Jul 11, 2002 8:09 am | |
| Marc van Kempen | Jul 11, 2002 8:11 am | |
| Marc Recht | Jul 11, 2002 8:13 am | |
| Georg-W. Koltermann | Jul 12, 2002 3:02 am | |
| Marc van Kempen | Jul 12, 2002 4:07 am | |
| Ernst de Haan | Jul 12, 2002 4:34 am |
| Subject: | Re: 1.3.1 patchset 7 not quite ready | |
|---|---|---|
| From: | Nate Williams (na...@yogotech.com) | |
| Date: | Jul 10, 2002 8:57:29 pm | |
| List: | org.freebsd.freebsd-java | |
It appears that signals may not be completely working as expected in -current, so you may have problems there as well.
If the only problems are userland (ie; libc_r), that's a really silly reason to abandon -stable for -current.
First of all, the code (HotSpot + libc_r) works better under -current than -stable. I've been tracking -current pretty closely and it's fine for what's being done at this point, signals are ok too.
Signals 'mostly work' in -current, regardless of what they do in HotSpot. You may end up chasing your tail trying to fix Java bugs that are in fact kernel bugs.
A differentiation needed to be made between my own development process and what will be available to the general community.
Ok, you can run whatever you like, but don't expect anyone to be able to help you. (The latter was sarcasm, since at the moment you're the only one doing any HotSpot development.)
By jumping to -current, you severely limit both the developers *AND* testers for the code, so you'll continue to be the one-man show.
If that's what you want, then you'll get your wish. If, however you want others to jump in and help you (as well as use the fruits of your labors), then we need to keep -stable a supported platform, even if it's non-optimal.
Right now they are different and it serves me best to continue with what I'm current doing otherwise I won't be able to make any more forward progress with this project.
Define progress? Getting stuff working under -stable is progress, and ripping the code out is certainly not progress.
As far as abandoning -stable, that'll be corrected once a libc_r merge happens. It's not really abandoning it per se as much as waiting for an essential component to be migrated over. When that happens, the two efforts will be unified.
Fair enough. Does Dan know exactly what parts of libc_r need to be merged back in? Can you help him out there, so that the changes are made back to -stable, so that other developers (and users) can get a chance at HotSpot? That would be a temporary setback for you as far as bit-twiddling and such, but it would bring the project and other developers much further ahead.
Nate
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message





