Faré wrote:

Dear Geoff,

...

...

If you are still interested in becoming ASDF maintainer, which I hope you are, or even just developer, here is a post linking to some suggested things to read about the state of ASDF: http://fare.livejournal.com/176185.html

I am still interested, even enthusiastic. I will read that and see how I feel with respect to time commitment and ambition. That said, I'm very much interested in taking part in ASDF, even if not in the capacity of maintainer.

[NB: continuing this previously private mail thread in asdf-devel]

If you're looking at where the action is, there are two branches that still haven't been merged into master:

• the minimakefile branch, where I translated all the release and test

code from shell scripts to CL scripts, with various improvements, paving the way for possible future improvements. I believe this branch is ready, but Robert is just lacking time to fully assess it; also, he was hoping for Kambiz Darabi's promised use of git submodules to manage all the dependencies of ASDF — though I don't believe this branch makes the issue any worse.

I got sidetracked by some other bugs that were more important. Since minimakefile is an alternative implementation for existing functionality that works, rather than either new functionality, or a fix to broken functionality, it's tended to get bumped off the priority queue.

I regard the git submodules as critical functionality for the minimakefile branch.

I have found even the existing make functionality brittle and fussy, because there is no good way to make sure that you have all the right dependencies installed and up-to-date. I suppose that we could make more extensive use of ASDF's version dependencies to detect such problems, but that would require more careful versioning of the lisp systems that the builder employs.

Quicklisp apparently has versions that are ok for now, but I don't regard that as an acceptable framework. It's not Xach's job to make sure that the ASDF build and test system works, and what if some urgent patch to a supporting system is needed to fix a bug manifested in ASDF's build?

ASDF needs a mechanism for people to easily get the correct versions of the systems it requires for its build.

Originally Kambiz talked about setting up submodules to meet this requirement. I'm not sure if he's still interested in doing that. If not, I'll try to have a look at doing it myself.

• the syntax-control branch, where I introduce control for the

*readtable* variable, allowing for safe compilation at a REPL (or other) where the *readtable* was overridden (to e.g. use fare-quasiquote or reader-interception, etc.) Unhappily, this branch requires more development: it seems that at least *package* needs the same treatment; and ideally all the variables of with-standard-io-syntax, though that might cause "interesting" backward compatibility issues. Also, Robert mentions that some large software he is using is somehow failing with this branch, for reasons he hasn't pinpointed. If and when this branch is merged into master (if ever), it deserves a version bump to 3.2 or some such. Even if the default changes to something safer than now, some backward compatibility mode is probably required to cater to the needs of all users.

Let's discuss this separately. It's a bigger topic.

In brief, though, this has not been a bug-driven development, so I have treated it as less than high criticality.

Robert may have further comments or clarifications.

In general, I have taken a less heroic view of the role of ASDF maintainership than Fare. Fare's was the heroic age, when ASDF was really a shambles, and would let its users down all the time: failing to notice when upstream changes invalidated a build, failing to correctly compute the set of operations needed, etc. Fixing this, cleaning up the object model, and getting ASDF to hot-upgrade itself gracefully, and portably, was a Herculean effort.

I regard my charter much more modestly, and much more in line with the term "maintainer." My job is to *maintain* the tool, fix bugs that are encountered (typically when a corner case is newly visited), etc. Mine is the perspective of someone who has a very large pile of CL code to keep running (portably), and for whom change comes at a high cost in verification of existing code.

I'm not saying that I would keep useful new features out of ASDF, but I do think that they have to be examined with a jaundiced eye, without rushing, and with a preference for not breaking existing code, and not complicating maintenance too much.

That is probably as close to a maintainer's manifesto as you will get from me.

Best, R