[Asdf-devel] ASDF

[Robert P. Goldman]

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