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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ asdf-devel mailing list [email protected] http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
