On Sat, Sep 11, 2010 at 7:41 PM, Faré
<fahree@gmail.com> wrote:
I hope that 2.008 will be my last ASDF release. I may still make
emergency bug fixes (if any is needed), or merge patches sent to me,
but I don't intend to actively develop ASDF anymore
Thanks for all your work up to now, Fare.
And so, ASDF is looking for a new active maintainer. To volunteer,
just start hacking on your own repo, and I'll hand you the keys after
I merge your first commit.
I have been traveling a lot these days, which is why I didn't notice this email before. But even after I read it, I got contradictory feelings.
On the one side, I strongly feel that something needs to be done with ASDF. As it is, it is an obstacle for the development and popularization of the implementation I work with. I keep getting reports of software that does not work with ASDF and ECL, libraries that render our standalone executable code useless because users are loading manually stuff from inside ASD files, because libraries are listed as load dependencies when they are only needed compile-time, because they are using ASDF symbols even in their own software without listing in any way a dependency for ASDF... Enough.
To this I have to confront several facts. One is that I am and will continue to be ECL's maintainer. The second one is that I like changing things and I like taking decisions and some of them are going to be very impopular (*). The third fact is that I have little time and this time will get even scarcer as I grow older and develop my own career in Physics.
What I mean with all this blah, blah, is that I would like to work on the next ASDF, with the help of those that volunteered to also collaborate in the release and bug control / reporting stuff, help which is really appreciated since I know how much a time saver that is. However, my volunteering comes with the expectation of no friction, no pressure and freedom to explore new ideas (some are quite clear in my head but need to see an implementation and a real life test). Do you think you can stand this? ;-)
The ASDF 2 source tree would remain as it is, with regular maintenance and extremely little and careful changes. Code could be reorganized so that ASDF 2 and 3 coexist sharing common bits (**), people would use either of them and I would mostly focus on the ASDF 3 part. This way if the project fails, we will always have ASDF 2, but at the same time hopefully things will improve and people will move towards the new, wonderful, powerful toolset that ASDF 3 should be.
Should people agree on my participation, I will definitely need help, for I know nothing of how ASDF's git tree or release process is organized.
Regards
Juanjo
(*) Forbid extending certain or even all ASDF's methods in user's systems (arbitrary load-op = no standalone or shipping), enforce test-op behavior, add install-op, add Makefile style rules to systems, merge load-op and load-source-op, split ASDF's source code, create a new ASDF loader that does not evaluate, introduce ASDF style warnings and loudly complain about crappy defsystems, crop the sources removing unused stuff (window's shortcuts?) and making it optional....
(**) I have a version of ASDF split into separate files that reconstruct the full picture. See