[Openmcl-devel] RFC - init-file and asdf:*central-registry* changes

[Gary Byers]

On Wed, 16 Feb 2005, Douglas Philips wrote:

>
> I'd also like to second Cyrus' earlier note, wondering what we in the
> gallery du peanut can do to prep. for a new release. Sadly my
> development environment is hosed, or I could try doing builds... (I
> might fix it, but then even I wouldn't hold my breath. ;-) ).
>
> <D\'gou
>

Back in December, the same question sort of came up; a few people
volunteered to help put together another distribution (to at least
package up all of the bug fixes in the last 8-9 months.)

I said "Great! let me set up CVS write access for you here, as a first
step!", then promptly got distracted by other things for a couple of
months.

I finally got guilted into taking an hour or two to do that a few
days ago; I've heard back from a few people (including Bryan) and am
still waiting to hear from a few others (who may have been distracted
by other things, themselves.)

Since guilt seems to be a motivating factor in my case, I'll try to
commit to something that I'd feel guilty about falling short on ...
How about "let's try for an 0.14.3 release - mostly bugfixes - by
the first week of March, and will try to commit time to package things
up and be involved in the process."

(Hmm; I feel guilty already, so that idea might work.)

Alex Crain has said that he has some improvements/reorganization of
Hemlock+Cocoa that he wants to check in.  (I'm not sure of the timeframe
and I'm not sure whether they'd still be experimental or more appropriate
for the main release.)  He'd also extended TRACE (so that callbacks can
be traced) and has some TRACE documentation ready or nearly ready for
release.

Helmut Eller's changes to get the FFIGEN stuff working with GCC 3.x
seem to work well (perhaps with minor tweaking.)  It'd be nice to be
able to package things up and make generating interface files a little
less of a black art.

There have been several discussions in the last several months about
trying to dress up support for passing certain types of lisp data
to foreign code.  Some of the ways of dressing things up would be
fairly ambitious, but there are probably also ways of making things
a bit easier to use (and being GC-safe at the same time) that are
fairly easy to do.

All of these things (and any other similar things that I'm not thinking
of) might be reasonable candidates for inclusion.  They might also
cause slippage in the (brand new) schedule.  I tend to think that the
most important 0.14.3 features are (a) getting current bugfixes into
a "stable" release and (b) trying not to break anything in the process;
if at least those goals can be reached in the next few weeks, I'd start
to feel less guilty.  (Maybe.)

If I'm correct in thinking this way, then one of the most important
things that can be done is to use the current bleeding-edge version
(soon to become the next release) and try to ensure that things
that're supposed to be fixed have been fixed (and that things haven't
gotten broken in the meantime.)  There's lots of stuff that people
use (ASDF[-INSTALL], CLX, ALLEGROSERVE, SWANK, ...) that I generally
don't use, and it'd be good to try to ensure that support for those
things doesn't get broken in a new release (or that broken support
has gotten fixed.)

Are there other things that I'm not thinking about that might be
reasonable (smallish) new-feature goals for a next release ?  Does
the time frame (~3 weeks or so) seem generally reasonable ?