[asdf-devel] ASDF 2.0 and beyond.

[Faré]

Dear Juanjo,

I'm sorry that my mail was taken the wrong way. It was only meant to explain
why I'm rejecting a lot of ideas *FOR NOW*, i.e. until ASDF 2.0 is out, even
though I'd like to see SAME IDEAS take form *AFTER RELEASE* and be merged in.
I actually agree with your approach and your propositions, I'm just
postponing them until after a 2.0 release.

My plan is to freeze the master branch at the end of April,
thereupon only accepting bug fixes or trivial enhancements,
and hopefully declare 2.0 released before the end of May.

I was suggesting that for the impatient, a 2.1 branch be created,
that would become the master branch after 2.0 is released
(with 2.0 itself becoming a secondary branch).

As for XCVB, I think that it would make a good start for an ASDF 3,
but that doesn't matter much.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
For pretty much every writer, the big problem isn't piracy, it's obscurity.
        — Tim O'Reilly, as cited by Cory Doctorow


On 20 April 2010 04:34, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> Dear Fare,
>
> I can not avoid to say that much of your previous email needed not be
> written.
> * THe warning about incomplete and bogus patches being submitted
> * The warning that the current maintainer knows it better the pain of
> maintaining and pushing new features.
> * Dooms about maintainers having to suffer the consequences of wrong choices
> right now and how bugs will pop up was unnecessary.
> * Equally so the warning that XCVB will gladly host all the lispers expelled
> from ASDF's imcompatible and disruptive changes.
>
> Why you could have saved that
>
> * First of all, the patches I submitted were never claimed to be final. I
> sent them because all i got was a no, no, bogus design, impossible, useless.
> I just wanted to show things can be done and can be used. This includes the
> extensions to OPERATE and TEST-OP to gather the lists of errors and make
> them really useful, the extension to include logical pathnames, the :TESTS
> annotation, the last extensions to make defsystem forms have dependencies...
> However this statement shows why this dialogue I attempted is futile: "I am
> not willing to either work out their issues or to delay ASDF 2.0 while said
> issues  get worked out."
>
> * Even if this a mailing list with a relatively low traffic, warning people
> about our desire to make ASDF behave incompatibly, or our incompetence to
> prevent bugs that will propagate to later releases is at the very least
> offensive. The first because it is wrong, the second because you yourself
> have introduced bugs and fixed them.
>
> * Encouraging *forks* of ASDF is just ungrateful to the project and only
> shows a, perhasp subconscious, will to weaken it.
>
> Let me get this straight.
>
> * I never spoke about making ASDF behave incompatibly in a disruptive way.
> This has been said by other people, here, at the ECL mailing list and at
> c.l.l. but I have always spoken against it.
>
> * I have always been talking about providing tools (i.e. annotations) that
> allow people evolve into a more declarative syntax, freezing it as the only
> one when and only when all the relevant packages get it right (99%? ASDF
> monitoring? These are and have been my words.)
>
> Juanjo
>
> --
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain)
> http://tream.dreamhosters.com
>