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

[Stelian Ionescu]

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.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20130302/55d7777c/attachment.sig>