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@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