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