On Sat, 2013-03-02 at 13:40 -0500, Faré wrote:
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?
It's a very good idea. The configuration mechanism is the last big hurdle preventing a virtual environment for Common Lisp. I think you should disable deferred warnings by default and keep filing bugs, postponing their re-enabling for 6-12 months.