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!
Since this entry is titled "Forks ..." (and not "Repository clones ..."), I guess that a fourth procedure can also be envisaged: if for some reason a project was forked, there's no reason why both the original and the fork could not be integrated into quicklisp, as long as the fork is renamed.
ReplyDeleteIf anybody wanted to provide a org.xyz.cesarum library forked from com.informatimago.common-lisp.cesarum, there'd be no problem with that (as long as the licenses are respected).