[asdf-devel] An upgrade path for checking deferred-warnings

[Faré]

Summary: I'm considering a "whitelist" approach for allowing old software
to be compiled without checking deferred warnings while they remain enabled
by default for all new software. But implementation is prolematic.


Over a week after I contacted every maintainer of a Quicklisp system
with a known issue with ASDF3, half replied only (26 out of 51),
most of them (19) by fixing the new found bug in their code,
a few of them (3) by declaring their package unmaintained
(lisp-on-lines cambl-test xmls-tools),
a few of them (4) working on it.

There may be more problematic systems not found by Anton's cl-test-grid yet,
because they depend on a system that breaks the build earlier.

Therefore, it seems unreasonable to expect all these systems to be updated
in a timely manner (or maybe ever at all).

Since the entire idea of ASDF2, as told in rpgoldman's and my 2010 paper
"Evolving ASDF: More Cooperation, Less Coordination" is that upgrading
should require less rather than more coordination between hackers,
it is time that I declare this simultaneous change towards checking deferred
warnings as a failure.

The question then being, what next? Is there any way that ASDF
can ever enforce new code restriction to help developers
without breaking things for users of existing software?


My proposal is that ASDF should have a new configuration mechanism
that lets users override some settings in other systems without
modifying the .asd file, and have default values for this mechanism
that disable the checking of warnings on old enough copies of a system.
ASDF would come with builtin such configuration (ignorable as usual
with :ignore-inherited-configuration)
to handle all the known systems that fail.

The detection of what system is "old enough" is itself a challenge.
Unhappily, git doesn't preserve timestamps by default (there are scripts
floating around to touch each file with the date of its latest modifying
commit, but that's not the default behaviour), and neither does darcs.
We therefore can't assume the filesystem timestamp of the .asd file
was preserved from the original source archive. We could then use
the asdf :version as the basis for such overrides, but that would force
the authors of any such system to adopt the ASDF versioning system
when they previously weren't.

What do you think?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Designing a computer programming system that doesn't address transactional
persistence means that you're proud of having no data worth keeping.