One bug down, one bug up

[Faré]

Dear future maintainers of ASDF,

I have great news for you if you were looking for an opportunity to
learn about the guts of ASDF: a new bug that will cover a lot of
ground, yet is relatively well-understood, and isn't urgent at all. I
wouldn't make it anyone's first bug, but once you have some
experience, it might be great bug to get really into it.

Context: I did this interactive debugging session, but it went quite
slow and after two hours we only narrowed down the root issue: we
needed the primary-system-* functions to distinguish between
"syntactic" and "semantic" primariness, since the two notions aren't
identical in the existing codebase, and my just ignoring the issue
caused these spurious rebuilds. I once again failed to properly record
the 2.5 hour interaction, but one of the participants might have done
so, though it's not as valuable as I'd have hoped. Then,
It took me the next morning to slowly develop a bug fix. See
explanation in the bug and code in the MR:
https://bugs.launchpad.net/asdf/+bug/1739514
https://gitlab.common-lisp.net/asdf/asdf/merge_requests/91

Now now now, while thinking very hard about the correct fix to the
above bug, and especially about the up-to-date-p condition in
find-system, I realized that there was a lingering bug in it, of the
kind order as the bug that broke ASDF 2, except in a much rarer
situation: if you update the defsystem-depends-on of a loaded system a
that could cause a change in how the a.asd file would be evaluated;
then this should trigger a reload of a.asd when you next operate on a;
but it won't because the timestamp is not propagated, because
find-system fails to integrate well enough with the dependency graph
usage and construction (which integration is new with 3.3).
https://bugs.launchpad.net/asdf/+bug/1741083

This seems to be like it's "just" a variant at the meta-level of the
famous bug that broke ASDF 2 (see my 25 page paper on the history of
ASDF about that). Except that now the infrastructure to propagate
timestamps, what more across evaluation phases, already exists;
therefore fixing this bug should mostly "just" use the existing
infrastructure. Then again, it could possibly break the universe
again, though I bet it won't: I believe there should be "just" an
update of find-system and the creation of a new operation class
prepare-define-op.

In any case, not my problem anymore, because it's clearly not a
regression. But a great opportunity for whoever steps up and fixes
this bug and whatever else they find. You better step forward while
I'm still here to answer questions: considering how hard it was for me
to page back the crucial elements of the algorithm into memory after
just one year, don't wait.

PS: Another exercise for a future ASDF maintainer would be to do the
boring work and fix all the 300+ systems on Quicklisp that trigger the
bad-system-name warning, one by one. This is also a great exercise for
getting to know what kind of clients are around. And for fixing them
according to my best_practices document.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Every great truth begins as heresy and ends as superstition.
        — Thomas Henry Huxley