sablevm-developer

[Sablevm-developer] Warning: devel release approaching

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

Hi all!

Today David and I were granted write access to "bugfree"s. I have some
ideas how/when I see the devel release should happen, but I'd like to
hear comments, if you have better/different ideas/beliefs about it.

The plan - how I see it:
- I put current staging (preferably tarball created w/ 'make dist' into
Debian and let people (and autobuilders) test it for a short while
- make necessary bug fixes, but if there're not major showstoppers
- move current staging to bugfree and make a release (by a request
to Etienne to make a tags for it)
(and I finally package 1.1.0 for Debian ;-)

Now disclaimers:
- we need to document our numbering schema in Wiki (I'll do this)
- we can make another devel release in a few days if we have important
bugs fixed, I see no reason to impose any requirements on when devel
releases can happen
- apparently we have a regression in threading support as compared
to 1.0.9 release and I don't think we can release 1.2.0 w/ this unfixed,
but holding devel release will hurt more, than this problem alone.
- we should have a step-by-step "making a release" process described,
like ex. subversion (or ArgoUML?) guys have (I'll do this too)
- under the assumption that all bugs in SableVM are also present
in its Debian version - we encourage people to use Debian BTS,
(or -devel ML - after all it's _devel_ release).

Question:
- Do you know about any other regressions or bugs that we have
currently in staging? Please tell us.

If we're to wait for ideal conditions to make a release - they will
never happen. We have what we have and IMO it is more than good enough
for people to test it. In most of areas it is far superior to old 1.0.9.
And w/o testing we wont make it really bugfree.

Cheers,

				Grzegorz B. Prokopski

PS: I want the above to happen really soon now. I am just having
troubles making new classpath compile like I'd like it to be
(but it's debian specific thing, no worries) so it takes longer
than I'd like it to be. But I am really working on it.

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

[Chris P. <chr...@ma...>]

Grzegorz B. Prokopski wrote:
> Hi all!
> 
> Now disclaimers:
> - we need to document our numbering schema in Wiki (I'll do this)

I think I have most of this already written (see below).

> - we can make another devel release in a few days if we have important
> bugs fixed, I see no reason to impose any requirements on when devel
> releases can happen

In my opinion bugfree should be bugfree to the best of our knowledge. 
That's why staging exists.  There's a difference between bugs and 
missing features.  I think regressions, if they truly exist, should be 
fixed before release (people generally don't like previously working 
things to be broken in an upgrade).  Plus I personally could really 
benefit from having the threading bugs fixed if they do exist (at this 
point I am no longer submitting a paper in the next couple of days, so I 
can help work on this).

> - apparently we have a regression in threading support as compared
> to 1.0.9 release and I don't think we can release 1.2.0 w/ this unfixed,
> but holding devel release will hurt more, than this problem alone.

Is this the JGFSyncBench bug I was talking about?

I also noticed that sometimes mtrt does not produce 100% identical 
output (an extra blank line appears at the top).

> Question:
> - Do you know about any other regressions or bugs that we have
> currently in staging? Please tell us.

Not all of the JGF bugs seem like threading bugs.

> PS: I want the above to happen really soon now. I am just having
> troubles making new classpath compile like I'd like it to be
> (but it's debian specific thing, no worries) so it takes longer
> than I'd like it to be. But I am really working on it.

I have some code comments that might be useful (e.g. in prepare_code.c, 
types.h ... stuff like that).  I also have a preliminary script (that 
needs refinement) to permute through combinations of options to 
./configure (see permute-options in my sandbox).

I also have some stuff on:

1) Policies for contributing to SableVM
2) How to access Subversion
3) Branch management
4) Coding style

I tried making a .tex file with it, although I don't think that's a good 
way to go.  .texinfo would be much more useful (just like classpath). 
In any case, you can see it in .pdf format at:

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 
know.  Nobody has actually commented on this work yet -- is there 
something totally wrong with the content?

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

Cheers,
Chris

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

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

[Chris P. <chr...@ma...>]

Grzegorz B. Prokopski wrote:

> W li=B6cie z wto, 10-02-2004, godz. 00:23, Chris Pickett pisze:=20
>=20
>=20
>>I have some code comments that might be useful (e.g. in prepare_code.c,=
=20
>>types.h ... stuff like that).  I also have a preliminary script (that=20
>>needs refinement) to permute through combinations of options to=20
>>./configure (see permute-options in my sandbox).
>=20
>=20
> So that we didn't double the work, try this:
>=20
> cd
> wget http://gadek.debian.net/testing/testing.tgz
> tar zxvf ./testing.tgz
> cd ./testing
> nohup ./run-all &>./0MAIN.out &
> tail -f ./0MAIN.out
>=20
> Do it somewhere, where you have all sablevm's and classpath's deps
> available, and a fast inet connection. Look into "config" file ;-)
> Then look into the scripts. If you add "benchmarks" to the list of
> TESTS to run and to the list of BINARIES - it'll fetch and run
> SPEC98 benchmarks (that's why I don't advertise this).
>=20
> Warning: once you start it - to stop it you need to kill all these
> processes ;-) Sorry, I was more worried making it actually go.


Really, Greg ... we should sit down with Bruno and discuss his Ashes 2=20
benchmarking framework.  I think we need ONE benchmark system for the=20
whole of Sable, so that nobody wastes time with these little scripts=20
anymore.  It will require learning Python though.

Compiling SableVM is a separate matter though, and as for the=20
compilation stuff in sources-compile-install, look at

http://www.sable.mcgill.ca/~cpicke/files/permute-options

and you'll see how it can be useful almost immediately to generate all=20
possible combinations of options (okay, I just realized it should=20
probably be called "combine-options" ...)

Cheers,
Chris

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

[Chris P. <chr...@ma...>]

Grzegorz B. Prokopski wrote:

> 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.

So, do you want me to do it then?  Or will you?

$ svn ls --username chris svn+ssh://svn.sablevm.org/public

does not work for me right now.  It was working last night without the 
username even ... so in the meantime if you have access it is faster for 
you to check 1.0.9.

> The words to remember: _regression tests_ start to be _required_

I think all actual functionality regressions should be eliminated before 
the release.

> 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.


Have you looked at the JGF benchmarks yet?  It's not apparently GPL, 
LGPL, or public domain code, but the source is available.  I just sent 
them a mail about licensing.

JGF would be perfect to keep track of things like performance 
regressions as well.  Please download and run some of the benchmarks so 
that you see what I mean.

>>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 think we should focus on the JGFSyncBench bug and forget about the 
other stuff until that's fixed.  In my opinion, regardless of whether or 
not it's a regression, it's a serious bug -- the Java code that causes 
it is very simple.


>>I have some code comments that might be useful (e.g. in prepare_code.c, 
>>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 
> 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).


So, I will make a tag for you that can be merged into staging, after we 
fix JGFSyncBench.

Chris

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

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

On Tue, 2004-02-10 at 14:46, Chris Pickett wrote:
> Grzegorz B. Prokopski wrote:
> > 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.
> So, do you want me to do it then?  Or will you?
Please go on.

> $ svn ls --username chris svn+ssh://svn.sablevm.org/public
AFAIK --username is for http-dav access only. To specify a username w/ ssh
access go to ./.subversion/config and change the parameters passed to ssh.

> Have you looked at the JGF benchmarks yet?  It's not apparently GPL, 
> LGPL, or public domain code, but the source is available.  I just sent 
> them a mail about licensing.
Good. We'll see. No, I haven't looked yet and I won't be able to do that
for a while (I mean - it's easy to fetch and run it but some more deep
investigation should follow, which I just can't do right now.)

> JGF would be perfect to keep track of things like performance 
> regressions as well.  Please download and run some of the benchmarks so 
> that you see what I mean.
I will give them a try.

> >>I have some code comments that might be useful (e.g. in prepare_code.c, 
> >>types.h ... stuff like that).
> So, I will make a tag for you that can be merged into staging, after we 
> fix JGFSyncBench.
I am looking forward to do it

Cheers,

				Grzegorz B. Prokopski