Forks and Quicklisp

Each project in Quicklisp is drawn from a particular upstream source. For example, clsql comes from http://git.b9.com/clsql.git, vecto comes from http://xach.com/lisp/vecto.tgz, and alexandria comes from git://common-lisp.net/projects/alexandria/alexandria.git.

This information is tracked in a project on github.

If you find a bug in a project, you can report the bug to the maintainer and wait for them to fix it. After it's fixed, the next release of Quicklisp will include the fixed version. (If you're extra-nice, you can submit a patch along with a bug report to get it fixed more quickly.) That doesn't require any intervention or changes in Quicklisp.

What if the maintainer does not fix the problem? There could be a number of reasons for this, including a lack of time, lack of interest, missed communication, etc. The situation might be temporary or permanent. In some cases, the maintainer is unreachable and the project is effectively abandoned. Whatever the case, it may be time for a new maintainer and home for the project. If there is a new home for the project, Quicklisp's tracking information must be updated.

I prefer information about this change to come from the original maintainer. That is, I do not really like to get emails like this:

Hello, the fooble project has a bug that breaks the barble project. Please use my fixed version at ...

I would much rather get an email like this:

Hello, I created the fooble project but will not be working on it any more. The new maintainer is making updates in a new repo at ...

This is next best:

Hello, I contacted the original maintainer of the fooble project and have agreed to become the new maintainer. The new repo is at ...

This isn't feasible if the original maintainer is unavailable or unresponsive for a long period of time. But I would like to see an effort to make this kind of transition before updating Quicklisp. So this kind of email is third best:

Hello, I tried to contact the original maintainer of the fooble project but haven't heard anything back in months. I would like to be the new maintainer and the new repo, with fixes, is at ...

Thanks!

update pjb brings up an important point in a comment: A fork of a project is perfectly fine if given a new name!

October 2013 Quicklisp dist update now available

New projects: asdf-package-system, ayah-captcha, cl-binaural, cl-fgraph, cl-larval, cl-ply, cl-server-manager, cl-spark, curry-compose-reader-macros, drakma-async, draw-cons-tree, filtered-functions, graph, lisphys, mailbox, map-set, oneliner, pooler, readable, simple-currency, smackjack, snappy, spellcheck, tagger.

Updated projects: algebraic-data-library, antik, bt-semaphore, buildnode, caveman, city-hash, cl+ssl, cl-6502, cl-annot, cl-async, cl-async-future, cl-autowrap, cl-bencode, cl-cairo2, cl-closure-template, cl-css, cl-curlex, cl-data-format-validation, cl-dbi, cl-decimals, cl-dot, cl-epmd, cl-erlang-term, cl-fbclient, cl-gdata, cl-grace, cl-gss, cl-iconv, cl-jpeg, cl-markup, cl-memcached, cl-mongo, cl-mssql, cl-opengl, cl-parser-combinators, cl-paymill, cl-portaudio, cl-smtp, cl-test-more, cl-twitter, clack, cleric, clfswm, clinch, closer-mop, clsql-helper, clx, coleslaw, com.google.base, com.informatimago, commonqt, conduit-packages, dartsclhashtree, declt, eos, esrap, external-program, f2cl, firephp, gbbopen, gettext, hh-web, http-parse, lisp-gflags, lisp-interface-library, lisp-unit, log4cl, lparallel, lquery, macroexpand-dammit, marching-cubes, memoize, nibbles, opticl, optima, periods, postmodern, protobuf, py-configparser, quicksearch, rcl, repl-utilities, restas, retrospectiff, shadchen, shelly, sip-hash, slime, stmx, string-case, swank-client, swank-crew, trivial-gray-streams, trivial-ldap, trivial-tco, uiop, vgplot, weblocks, weblocks-stores, weblocks-tree-widget.

Removed projects: weblocks-utils.

I have reverted macroexpand-dammit to its original source, from John Fremlin. Hopefully that will clear up some recent problems.