> Gábor Melis wrote:
>> Mailboxes are different. I can imagine variations on this theme (with a
>> priority queue instead of a fifo for example or not waking up all
>> blocked readers ...) and that makes me say that this kind of
>> functionality ought to belong to a library or a contrib.
> This brings up a question on a subject I've always been a little fuzzy
> on: how do things end up in contrib?
I think the old informal procedure was something along the lines of
"somebody wrote cool code for CMUCL, let's port it over and package it
up", but that doesn't really apply these days. Contribs have been
added quite rarely lately (over 1.5 years since the last one), so
there's no current procedure, formal or informal.
My intuition is that new contribs have a better chance of getting
included now if they fit into one of the existing contrib categories:
* Bootstrapping easy library installation:
asdf, asdf-install, sb-bsd-sockets, sb-posix
* Provides extensions that are tightly linked to specific SBCL versions
due to use of unexported interfaces:
sb-aclrepl, sb-cltl2, sb-introspect, sb-md5, sb-simple-streams,
* Used by other contribs:
sb-grovel, sb-rt, sb-rotate-byte
Other code is probably better off as an asdf-installable library.
SB-MD5 might not make sense as a contrib by this criteria since its
use of unexported guts is pretty trivial, but it's grandfathered in.
There's also a fourth "I have no idea of why this is a contrib, does
anyone even use it?" category that contains "sb-executable". We
probably want fewer, not more, entries there. ;-)