How would you feel...

[Faré]

> OTOH, it's probably A Bad Thing if you depend on a system for something
> you are doing, and don't know what license it uses.
>
Well, we haven't codified any format for :license. I suppose we could adopt
the nomenclature used by Debian. Except what in Lisp circles goes by
the name "MIT"
(as notably used by ASDF itself) in Debian-speak is called "Expat".
Also, we don't have a story for multi-licensed code either.
For instance, I have code under LLGPL or bugroff, or BSD or bugroff.

> But that's why I created a special class of CONDITION for this case --
> so you can muffle it if you don't care.  It would be nice if there was
> some way to detect the distinction between internal systems (fix them!)
> and external systems (muffle).
>
At ITA, we started with muffling the external systems, but quickly
enough decided to fix them instead; code quality matters for libraries
we depend on, too. But we did have a list of style-warnings to muffle
and some of them were based on dependencies indeed.

> I'll push my topic branch today.  It needs a test script, and I'd like
> to make it skip signaling on "slashy" subordinate systems, but I'd love
> comments in the meantime.
>


>>> I'm concerned about postponing this because I don't see implementations
>>> -- *especially* the commercial ones -- picking up ASDF revisions quickly.
>>>
>> I'm not sure how postponing will make implementations pick ASDF up faster.
>> The frustration about that next feature not going to make it to
>> implementations nearly as fast as you'd like
>> is going to be with you no matter what. Count one year for adoption by
>> "early adopters",
>> and two years for ubiquitous adoption. That was the approximate delay
>> for both ASDF 2 and ASDF 3.
>> Delaying a release by a few weeks doesn't make sense in contrast.
>
> I figure it's rate limited, not time limited.  I.e., I get a limited
> number of opportunities to have the implementations pick up an ASDF, so
> I'd like to pack in as many fixes and enhancements as possible.
>
I'm not sure that's correct. IIUC, there are three kinds of implementations:
1- those have their own slow release schedule, independent from
ASDF's, and our goal is to convince them to include "update ASDF" in
their release checklist.
2- those that do not have a release schedule, and our goal is to
convince them to "update ASDF" in a timely way after it is released.
3- Implementations such as SBCL that release regularly and often, and
couldl adopt either strategy (but, in the case of SBCL, doesn't
really).

Release fatigue would only happen if you released so often that you
annoy those who follow strategy #2. Maybe that's what happened with
SBCL.
Somehow, I don't see this happening with ASDF anymore, unless you have
hidden development plans.

>> That said, it'd be nice if the following implementations upgraded more
>> often: Allegro, CLISP, ECL, SBCL. The former two haven't reached ASDF
>> 3.1 yet.
>
> My copy of Allegro is at 3.1.4.3.  They have issued at least two ASDF
> patches since the 9.0 release.
>
My allegro express is stuck at 3.0.2.3, but maybe the issue is a
failure of the ./update.sh script, which may be due to my Ubuntu not
supporting the 32-bit graphic libraries used by Allegro.

> clisp seems to have given up releasing.
>
I've seen a call for new maintainers relayed by Xach.

> I'm excited to see ECL get revitalized now that it has new maintainers.
>
Yes. And it has a relatively recent ASDF 3.1.2, though 3.1.4 would be better.

> My SBCL is at 3.1.3.  I think 3.1.4 is solid enough that it should be
> updated there.
>
I've bugged SBCL hackers many time since last october, to no avail.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
In reviewing the history of the English Government, its wars and its taxes,
a bystander, not blinded by prejudice nor warped by interest, would declare
that taxes were not raised to carry on wars, but that wars were raised
to carry on taxes.              — Thomas Paine, "Rights of Man"