Re: [Sablevm-developer] Warning: devel release approaching

[Grzegorz B. P. <ga...@de...>]

W li=B6cie z wto, 10-02-2004, godz. 00:23, Chris Pickett pisze:=20
> Grzegorz B. Prokopski wrote:
> > - we can make another devel release in a few days if we have importan=
t
> > bugs fixed, I see no reason to impose any requirements on when devel
> > releases can happen
>=20
> In my opinion bugfree should be bugfree to the best of our knowledge.=20
> That's why staging exists.  There's a difference between bugs and=20
> missing features.  I think regressions, if they truly exist, should be=20
> fixed before release (people generally don't like previously working=20
> things to be broken in an upgrade).  Plus I personally could really=20
> benefit from having the threading bugs fixed if they do exist (at this=20
> point I am no longer submitting a paper in the next couple of days, so =
I=20
> can help work on this).

Yes, that's exactly what I mean: _regressions_ - these should be removed
before the release. Ex. I'll be fighting w/ one such today. That's also
why I want to *know* (not suspect) whether things worked w/ released
1.0.9 or not. This doesn't change the fact that these problems are to
be fixed.

But it does change level of the devel-release-readyness of our codebase.
Definitely there should be no regressions in bugfree.

OTOH I think everybody agrees that we're in a need of release, so I am
a bit inclined to loose the requirements *a little bit*, but it'd need
to be evaluated on case-by-case basis. That's why I want to know what's
the current state compared to old 1.0.9.

The words to remember: _regression tests_ start to be _required_

Especially if we want to seriously treat our users (and ease our work in
the long term). Temporarily we can use some proprietary benchmarks and
the like for this purpose, but eventually - we should have a set of
little but free tools that stretch the JVM in a few directions. Like
BTF does it for inlined and architecture-specific problems (ex. in
arithmetic and signal handling). Ex. Mauve is good, but it targetts
more Classpath, not the JVM.

> I also noticed that sometimes mtrt does not produce 100% identical=20
> output (an extra blank line appears at the top).
Yes, mtrt causes many problems, _also_ on single-cpu processors on
_some_ achitectures. They are sometimes more serious than an extra
blank line. It's the state of affairs w/ current staging. Can't say
about 1.0.9 yet. Might be hard to compare on some arches.

> > Question:
> > - Do you know about any other regressions or bugs that we have
> > currently in staging? Please tell us.
>=20
> Not all of the JGF bugs seem like threading bugs.

So we're even more in a need of nailing them down (at least documenting,
possibly fixing).

> I have some code comments that might be useful (e.g. in prepare_code.c,=
=20
> types.h ... stuff like that).

Maybe at some point (not now) you should try to think about merging
some of that? We already have some interesting things in sandboxes, but
if nobody does the work required to make them ready for staging and=20
actually do the integration - these things just get older and don't
benefit anybody (like hppa port I tried to ressurrect lately or Cygwin
port in Melanie's sandbox).

> http://www.sable.mcgill.ca/~cpicke/public_html/files/HACKING.pdf
> if you don't want to check it out of my sandbox.  It's kind of ugly, I=20
> know.  Nobody has actually commented on this work yet -- is there=20
> something totally wrong with the content?
Put on my TODO.

> In my opinion, it might be worth consolidating all of the files in the=20
> sablevm/doc directory into a .texinfo file prior to release.

I like the direction. But let's squash some bugs first, okay? ;-)
(especially if they're regressions)

Cheers,

				Grzegorz B. Prokopski

--=20
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM