2009/12/18 Samium Gromoff <_deepfire@...>:
>>> I realise that it's quite possible that everybody "who matters" attended SBCL10,
>>> but, do you think it'd be beneficial if somebody provided a summary on this?
>> The original message probably lacked some context. Do we want an alternative release
>> with third-party libraries included, and if so, which ones?
> If we do, an obvious candidate is libcl, courtesy of Daniel Herring:
This is going to be a tricky discussion, because we have a reasonable
start of a discussion from SBCL10, but anyone who wasn't there is
going to get "we already talked about that" thrown in their face a
What follows is what I think, informed by what we talked about so far
-- but it's not something anyone else necessarily agrees with. That
said, I think it does summarize several of the points made at SBCL10.
Kind-of like libcl, but not quite
* SBCL specific libraries fine, encouraged in fact. (But things like
CFFI are fine too, of course.)
* Include libraries based on the directions of the library
maintainers: ask maintainers of each library (1) are they OK with the
bundling (2) which version should we bundle and how often should we
update (3) how do they want bugreports handled?
* License: libcl doesn't guarantee MIT/BSD compatibility right now,
and I think we want that?
* Contents: I don't actually have any major gripes with libcl
contents, except I'm pretty sure we don't want to bundle quite so much
at least to start with. Basically, unless the upstream author is
actively following our bugreports to pick ones that deal with their
library I would hope that at least one SBCL developer is familiar with
the library before we include it. Otherwise we can't make an informed
selection and users asking for help are not going to get any.
* Documentation: while SBCL is not a poster child for documentation by
any means, I don't think we should include utterly undocumented
things. Since HTML is the common nominator these days we may want to
consider making HTML the main documentation format for SBCL as well
and link the library docs into main SBCL docs. (Rudi?)
[ While from our users perspective the difference between libcl and
SBCL extras may be minimal, I think from our perspective there are
several points where goals and constraints diverge somewhat. ]
* Think about how things like Linux distros should package this. James
Knight (IIRC) suggested that mostly the right thing might be
unbundling into several packages and making SBCL recommend them (in
the apt-sense of the word.)
* Make sure we don't annoy users or upstream hackers. I _must_ be easy
to get either the bundled version or the alternative locally hacked
* Doesn't really matter if it is a separate extras/ directory in the
repo, or a separate repo entirely. Doesn't really matter (to me at
least) if it is a single download or some on-demand thing.
* I would be nice if APROPOS (or equivalent) knew about the contents
of these libraries, so that people could figure which library to look
at using an interactive tool instead of a webpage.
* Abuse our market position to give a boost to things we think are worth it.
* People new to lisp don't have any reasonable way to conclude that
CXML is probably what they want for XML processing, and similarly for
any number of tasks. People _old_ to lisp can also fail at this
spectacularly just because the world is large and no-one can keep up
with it all. While this means that neither can we, we can at least let
our users know about the bits of the world we do keep up with.
There was other stuff in there as well, but I think this covers it mostly.
In the abstract, we want an infrastructure we can put stuff into, and
a process for putting stuff in there. :)