Ralf Mattes rm@seid-online.de writes:
On Thu, Jan 23, 2014 at 10:05:55AM -0500, Zach Beane wrote:
Marijn Haverbeke marijnh@gmail.com writes:
Yes, recently someone submitted a patch that broke a bunch of things. It has already been reverted in the git repository, but I guess quicklisp picked up the broken version (since it seems to assume that repositories are never broken). Update from git, I guess.
Urghs, I just created some (Debian) package building scripts that rely on Quicklisp (i.e. that install a temporsry quicklisp to build standalone binaries). The idea that quicklisp might deploy some arbitrary checkout makes me frown.
It does use arbitrary checkouts for many projects. There are many useful projects for which that is the only way the software is made available.
Most of the time it works ok, but sometimes it doesn't. I'd like to improve the situation, but it takes time.
I don't assume that repositories are never broken. I don't have a good system in place to do pre-release testing beyond "Does it build?" I'd like to do more thorough testing, but setting up the infrastructure for it takes time.
It might be a good idea to offer the upstream programmers a way to provide a branch/tag to mark quicklisp ready versions of the code (I personally use git-flow and that has a branch named 'release').
Not a lot of Quicklisp-provided projects follow this convention, but when they do, I try to use it.
Zach