[asdf-devel] New ASDF maintainer sought

[Juan Jose Garcia-Ripoll]

On Sat, Sep 11, 2010 at 7:41 PM, Faré <fahree at 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
http://tream.dreamhosters.com/git/index.php?p=lisp/asdf-decl.git&a=tree

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100916/dd434503/attachment.html>