> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Brian Jones
>
> "John Keiser" <[EMAIL PROTECTED]> writes:
>
> > To that end, here are the minimum requirements I can think
> of for very
> > first public alpha release:
> >
> > 1. Everything builds out of the box. Warnings allowed, errors not.
>
> Actually I wouldn't put this constraint on it. It is unlikely
> Classpath will initially compile on anything but whatever the
> developers have used to create it. To my knowledge that is mostly
> Linux. Ports will come after other people have had a chance to try
> building it and noted the problems.
>
It doesn't *have* to work on any system, just Linux is fine, I should have
specified that. We will, of course, specify what you need to have on the
system to work: Linux, libc (version?), Guile, Japhar, and Java (right now
at least).
> > 2. Self-contained: does not require Sun's JDK to fill in missing
> > classes.
>
> I should probably check to see where we are on this. I know all those
> java.lang.*Error classes have to be created. That's on my TODO list.
>
We also need Float and Double, and there are some compilation errors. I
think we're very close on this.
> > 3. Passes all the tests Japhar normally passes.
>
> I don't think this is really required.
>
I don't think Japhar's tests are really all that complex, and I'm not in the
mood to create any more tests just yet. I am basically speaking of basic
net support, basic I/O support, basic language support. I am not talking
about requiring Classpath to be able to handle the space shuttle just yet :)
Basically, passing Japhar assures us a *minimal level of usability*. That's
what I'm aiming at.
> > 4. A tested cleanroom release requiring only ./configure;
> make; make
> > install that does all of the above.
>
> See 1.
>
See my reply to 1. Given installations of the things we require them to
install on Linux, ./configure; make; make install should work fine.
Requiring options to configure is OK too.
> > 5. All files have the proper copyrights on them (most
> don't right now,
> > including mine)
>
> Noticed that. I placed copyrights on everything I've done (that I can
> think of). Paul needs to get with me to take care of the copyright
> assignment paperwork.
>
I have copyrights on most of my stuff; I just haven't updated them to say
"Copyright GNU" instead of "John Keiser".
> > At that point, we can release an alpha on the website and
> let people
> > know about it. I call it alpha because it is incomplete; that
> is, it does
> > not have all of the classes we set out for a first final release. Beta
> > would probably work OK as a moniker.
>
> In gnu-dom, an alpha release is okay. With an alpha release there
> should be a file called README-alpha explaining the release, etc.
>
That's fine ... the main question is, though, do you think the requirements
outlined above constitute a beta or an alpha?
> Following recommendations from ers, any free software project should
> release early and often. As we have anonymous CVS available I think
> that is accomplished. Next is having a lot of documentation. I think
> we're actually still behind in that area. Finally there is having
> something which can be used, so that bugs and problems can be found.
>
You're right. CVS takes care of that first requirement. And we don't
automatically generate JavaDoc, but we are in a special position in that
Java is already very well documented and at this stage we're just
replicating, not innovating. Everyone knows how it should work.
The release I am talking about is your "having something which can be
used" requirement. That's why I'm talking about a working alpha release: to
bring in hackers, testers.
--John Keiser
> Brian
> --
> |-------------------------------|Software Engineer
> |Brian Jones |[EMAIL PROTECTED]
> |[EMAIL PROTECTED] |http://www.nortel.net
> |http://www.classpath.org/ |------------------------------
>
>
