[armedbear-devel] Bug triaging / new milestones available

[Erik Huelsmann]

Hi Blake,


> Having a version number of zero point anything sends a message that
> the application is not yet meant for real, production use.  I see ABCL
> as being sufficiently complete and reliable as to warrant a 1.0
> release.  Enhancements and bug fixes will likely go on indefinitely.
> The question is, is ABCL sufficiently complete and reliable to be
> called Common Lisp and used in a production environment?  If the
> answer is yes I think a version 1.0 is due.  If the answer is no, what
> are the steps necessary to get it there?

When we took over from Peter Graves (late 2008) we discussed which
goals to achieve. Even back then ABCL was rather stable, even though
it was failing hundreds of ANSI tests and couldn't even run Maxima.

The goals we set back then were:

1. A high-quality Common Lisp implementation - which would be called
1.0 - defined by the following criteria:
   a. Feature complete w.r.t. CLHS
   b. Support for some regularly supported features, minimally
requiring Gray streams (many Edi packages depend on them)
2. A CL implementation with (full) AMOP support - to be called 2.0

Note that we never defined (1.a) to be without bugs. The only thing
we're lacking at this point with respect to (1.a) is that our
DEFINE-METHOD-COMBINATION support is still experimental. I'm not aware
that we're lacking any other (required) features.

With respect to (1.b) I'd like to note that I think our Gray streams
support works most of the time, but has got some fundamental flaws we
have started to address, but never completed. The issue here is that
our internals are not correctly set up to handle generic CLOS objects
as stream objects: they'll only handle our existing
Java-stream-wrapping-LispObject-derived-Stream's.


We have defined "being a high quality Common Lisp" as being able to
run many of the readily available software; some examples:

 * Being able to be a build-host for SBCL
 * Being able to run Maxima's test suite
 * Being able to run CL-BENCH

And with the advent of Quicklisp (http://quicklisp.org/), I'd like to add

 * Being able to compile the top 30 downloads from quicklisp (found
here: http://xach.com/tmp/downloads.txt)
  [Note that personally I find "being able to compile" not a very high
bar, though, it's a start.]


Talking to others about ABCL, I find that a high quality CL
implementation is probably also defined by the documentation that's
available for it - meaning that I think we should probably write more
documentation for ABCL if we really want to reach huge levels of
attractiveness.

The releases we have seen so far are mostly working toward the goals
formulated above. At the same time, we have been working on other
important goals, though, such as:
 * making embedding easier
 * increasing general stability of ABCL
 * specifically, increase stability under multithreading circumstances
 * fixing CLHS conformance issues
 * improving user experience


I know the zero-dot numbers are really low and giving the wrong
signal. However, I hope that the fact that we release bi-monthly with
significant change lists does counter that a bit. The same goes for
our list of testimonials.


Yesterday, I talked to Ville on IRC (irc://chat.freenode.net/#abcl)
and we agreed that ABCL being an SBCL buildhost would be a good goal
to put back on the agenda for 0.26 (and possibly beyond). ABCL used to
be able to build SBCL many moons ago, but unfortunately, that's no
longer the case due to changes in SBCL which expose issues in ABCL.

What's your reaction to the above? Does it sound like a plan?


> I didn't see a "Roadmap" link on the ABCL page.  That would be great.

Thanks for your comments. It's the easiest start for documentation
that we can make. I'll definitely rewrite the above into such a page.
The page to be created will reference our 'bug fixing planning page'
[http://trac.common-lisp.net/armedbear/roadmap] too, btw. You may want
to check it out, if you're not familiar with it.


Bye,


Erik.