Dear all,
I think that Juanjo's and Janderson's propositions are on the right track, and I'm glad Juanjo is stepping forward as ASDF maintainer. I just have a few points to make:
* while being the XCVB author and ASDF maintainer, I've become acutely aware of the distance between a simple idea, a prototype that works in the common, a robust product that works in all cases, and a robust documented library that is suitable for developers, and a polished product that is usable by end-users.
* I don't think it's demeaning to say that the prototypes developed by Juanjo or James are not polished products yet. I could argue at length on the details, but my main point in not including them so far is that I don't think they are ready for primetime, and I am not willing to either work out their issues or to delay ASDF 2.0 while said issues get worked out.
* When Juanjo, Janderson, or someone else takes over after 2.0, it will be time to mainline those ideas, and the new maintainer will have to do the painful work of resolving each and every bug until the code is right. Ouch.
* You don't have to wait until after ASDF 2.0 is released to start branches or alternate repositories. I would encourage the creation of such branches.
* Be aware that no branch should be merged in until the code is robust enough, usable by its target audience, and has someone willing to fix any issues that come up with testing (and, ideally, includes proper unit tests).
Now, as of the development and testing process,
* I think Juanjo's investigation of ASDF practice is essential in establishing what "backwards compatibility" is really needed. If we know exactly which packages are affected by some change, we can make that change and fix those packages.
* Janderson's automated testing is also a huge step in the right direction. As with the ASDF internal test suite, the goal would be to first establish a baseline what backwards-compatible build success is, and from there be able to detect and fix regressions.
As for future developments:
* I think the design goals that Juanjo put forward are pretty uncontroversial.
* I will happily argue the devil out of the details of the proposed patches, but not in this conversation thread.
* Having revamped the internals of TRAVERSE for performance reasons (but without changing its semantics), I can tell: it sucks, and no one can sanely be relying on its precise behavior. Don't be afraid of replacing it.
* When I started XCVB, I didn't think that ASDF was salvageable, either technically or politically. Thank all of you who participate on this list for proving me wrong.
Regarding XCVB itself:
* XCVB already embodies a lot of the principles outlined by Juanjo in this thread and on c.l.l, and what it doesn't have yet it certainly was intended to have eventually. http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/9451a5209...
* XCVB notably has declarativeness of the system specification, support for generated files, lisp images, cross-compilation, a compile-and-link model, warning control, etc.
* Like ASDF, it is lacking good support for testing, documentation, foreign language compilation, shared libraries, general rules, etc., although allegedly the basic model of XCVB has room for them in a way that isn't true for ASDF.
* It is also lacking things that ASDF has, like support for more implementations than SBCL, CCL, CLISP, a good extension mechanism and its actual application to compiling CFFI, Ironclad, a working WITH-COMPILATION-UNIT, etc.
* If you manage to salvage ASDF and make it evolve incompatibly towards more declarativeness, XCVB will happily be fully compatible with the new, better ASDF. XCVB might then become "just" an alternate, out-of-image cross-compiling implementation of the ASDF specification.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] In the long run, John Maynard Keynes is dead. — John Perich