[asdf-devel] New ASDF maintainer sought

[Faré]

Dear all,

I welcome both Vsevolod's and Juanjo's candidacies to overtake ASDF
maintenance. Let the one who actually has time to do the hard work do
the hard work and take over. However, while I generally agree with
both of your plans with respect to the future of ASDF, I have a few
remarks.

* Moving towards more rational release numbers is good.
* A regular release cycle is only justified if there are regular changes.
* Moving towards a fully declarative model is I think essential,
 though of course it does requires a clear split between
 backwards-compatible 2.x and incompatible 3.x.
* supporting more ops is cool: test-op, install-op, etc., but of course
 is probably to be done as (standardized) extensions rather than as more
 stuff in asdf.lisp

Against a point that you both raised,
I see no good reason whatsoever to split asdf in multiple files,
though I can imagine plenty of bad reasons from past conversations,
and I see plenty of good reasons not to do it.

Bad reasons to split:
* ease of browsing? Nope, it's harder when split.
 You have to search for text in all files,
 lookup an index to see the order (that does matter).
* speed of compiling? Nope, for hours of maintenance, you only get a few
 fractions of a second of speedup in the rare case that you only make
 a simple change to a file that leaves all APIs untouched. And only on
 a few implementations where you can somehow achieve separate compilation
 through ad-hoc non-portable scripts. Full build takes a fraction of a second
 MORE time, not less time, when you first have to concatenate all the
 subfiles, anyway, because in the end, the reason we put it all into
 asdf.lisp is because it was all necessary to bootstrap ASDF.
* ease of maintenance? Nope, additional maintenance nightmare.
* ease of distribution? Nope, it's easier to distribute one Lisp file
 than a directory of files.
* ease of deployment? Nope, it has to be loaded all at once,
 and there's no portable way to concatenate FASLs.
* ease of bug tracking? Nope, it's easier to md5sum or diff one file
 than to try to assert and maintain coherence between tens of files.
* smaller size? Nope, you only increase the total overhead,
 and don't diminish the intrinsic complexity and size.
* more sizeable chunks? Nope, my screenful of emacs buffer remains
 of the same size.

I'm sure we could figure out or imagine more reasons and non-reasons.
But in the end, before you do such a sweeping change, can we have
a rationale?

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Question:  How many Intel/Microsoft executives does it take to screw in a
light bulb?


Answer:  None, they simply make darkness an industry standard.



On 16 September 2010 17:42, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> 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
>