About holding the release briefly while I negotiate with Xach about metadata?
Xach is starting to make QL complain about systems missing AUTHOR, DESCRIPTION, and LICENSE. I'm pushing for VERSION, as well.
I was thinking of adding a new class of STYLE-WARNING for systems that are missing that metadata.
Given that it's hard to get ASDF versions into implementations, I'm considering holding on this briefly.
I'll put in a topic branch for this.
cheers, r
Oh well, I'm torn. I think it's a good thing, but maybe incompatible enough that we should release 3.1.5 now and start a 3.2.0 branch.
On Tue, May 26, 2015, 12:20 Robert P. Goldman rpgoldman@sift.net wrote:
About holding the release briefly while I negotiate with Xach about metadata?
Xach is starting to make QL complain about systems missing AUTHOR, DESCRIPTION, and LICENSE. I'm pushing for VERSION, as well.
I was thinking of adding a new class of STYLE-WARNING for systems that are missing that metadata.
Given that it's hard to get ASDF versions into implementations, I'm considering holding on this briefly.
I'll put in a topic branch for this.
cheers, r
Faré wrote:
Oh well, I'm torn. I think it's a good thing, but maybe incompatible enough that we should release 3.1.5 now and start a 3.2.0 branch.
I don't think this counts as incompatible, since it would only be a STYLE-WARNING (so not break anything).
I'm concerned about postponing this because I don't see implementations -- *especially* the commercial ones -- picking up ASDF revisions quickly.
So I view ASDF releases as a very finite resource, and one where we have to get the most bang for the buck.
I'd rather postpone than push a release out the door, and maybe find it's the only one that the implementations will bundle for this year.
Cheers, r
On Tue, May 26, 2015, 12:20 Robert P. Goldman <rpgoldman@sift.net mailto:rpgoldman@sift.net> wrote:
About holding the release briefly while I negotiate with Xach about metadata? Xach is starting to make QL complain about systems missing AUTHOR, DESCRIPTION, and LICENSE. I'm pushing for VERSION, as well. I was thinking of adding a new class of STYLE-WARNING for systems that are missing that metadata. Given that it's hard to get ASDF versions into implementations, I'm considering holding on this briefly. I'll put in a topic branch for this. cheers, r
On Tue, May 26, 2015 at 2:55 PM, Robert P. Goldman rpgoldman@sift.net wrote:
Faré wrote:
Oh well, I'm torn. I think it's a good thing, but maybe incompatible enough that we should release 3.1.5 now and start a 3.2.0 branch.
I don't think this counts as incompatible, since it would only be a STYLE-WARNING (so not break anything).
At ITA we used to consider any uncaught STYLE-WARNING at breaking the build, which allowed us to keep our codebase clean and not drown useful warnings in a sea of noisy messages. I suppose other CL shops might do as well. Of course, they could "just" patch their dependencies to hush this warning, as we would have done.
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.
So I view ASDF releases as a very finite resource, and one where we have to get the most bang for the buck.
That's probably true to a point for major releases (e.g. if you wanted to make a milestone release 3.2), but minor releases seem to not be as much of a hassle. That's why I believe a safe plan is to release 3.1.5 now and indeed wait a bit for a 3.2 release, after we merge the more "experimental" code.
I'd rather postpone than push a release out the door, and maybe find it's the only one that the implementations will bundle for this year.
Once you accept that vendors don't care about your schedule and work by their own, your life becomes less stressful. The big hard pushes were for ASDF 2 then ASDF 3, where it was important that every implementation should provide the new major release for compatibility reasons. To a lesser degree it would be nice if everyone could rely on ASDF 3.1 (and we should hopefully be there next year), but now that ASDF 3 has auto-upgrades that work without kinks (as opposed to ASDF 2 where they worked but only if the user exercised extra caution at startup or ASDF 1 where they didn't work at all), users unhappy about their implementation's release schedule can easily install an upgrade and forget about it.
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.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Always design a thing by considering it in its next larger context — a chair in a room, a room in a house, a house in an environment, an environment in a city plan. — Eliel Saarinen
Faré wrote:
On Tue, May 26, 2015 at 2:55 PM, Robert P. Goldman rpgoldman@sift.net wrote:
Faré wrote:
Oh well, I'm torn. I think it's a good thing, but maybe incompatible enough that we should release 3.1.5 now and start a 3.2.0 branch.
I don't think this counts as incompatible, since it would only be a STYLE-WARNING (so not break anything).
At ITA we used to consider any uncaught STYLE-WARNING at breaking the build, which allowed us to keep our codebase clean and not drown useful warnings in a sea of noisy messages. I suppose other CL shops might do as well. Of course, they could "just" patch their dependencies to hush this warning, as we would have done.
We do this for our Jenkins CI jobs, too. I suppose I might change that policy for systems we depend on, as opposed to systems we build.
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.
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).
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.
So I view ASDF releases as a very finite resource, and one where we have to get the most bang for the buck.
That's probably true to a point for major releases (e.g. if you wanted to make a milestone release 3.2), but minor releases seem to not be as much of a hassle. That's why I believe a safe plan is to release 3.1.5 now and indeed wait a bit for a 3.2 release, after we merge the more "experimental" code.
I'd rather postpone than push a release out the door, and maybe find it's the only one that the implementations will bundle for this year.
Once you accept that vendors don't care about your schedule and work by their own, your life becomes less stressful. The big hard pushes were for ASDF 2 then ASDF 3, where it was important that every implementation should provide the new major release for compatibility reasons. To a lesser degree it would be nice if everyone could rely on ASDF 3.1 (and we should hopefully be there next year), but now that ASDF 3 has auto-upgrades that work without kinks (as opposed to ASDF 2 where they worked but only if the user exercised extra caution at startup or ASDF 1 where they didn't work at all), users unhappy about their implementation's release schedule can easily install an upgrade and forget about it.
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.
clisp seems to have given up releasing.
I'm excited to see ECL get revitalized now that it has new maintainers.
My SBCL is at 3.1.3. I think 3.1.4 is solid enough that it should be updated there.
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"
On Tue, May 26, 2015, 12:20 Robert P. Goldman rpgoldman@sift.net wrote:
About holding the release briefly while I negotiate with Xach about metadata?
Xach is starting to make QL complain about systems missing AUTHOR, DESCRIPTION, and LICENSE. I'm pushing for VERSION, as well.
I was thinking of adding a new class of STYLE-WARNING for systems that are missing that metadata.
Given that it's hard to get ASDF versions into implementations, I'm considering holding on this briefly.
I'll put in a topic branch for this.
cheers, r
As I'm editing my systems to include the requested metadata, I realize that this can be quite cumbersome for secondary systems (mostly test systems).
Can we exempt secondary systems "foo/bar" from having to repeat the metadata from primary system "foo"?
And what if the test system is call foo-test in its own .asd file? Does he then have to repeat the metadata?
While I like the idea, I think we shouldn't hurry and release something before we have figured out those details.
Once again, I feel like we should release what we have as 3.1.5, and start a new 3.2.0 alpha branch where we merge our experimental code.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The whole aim of practical politics is to keep the populace alarmed (and hence clamorous to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary. — H. L. Mencken
-
Faré -
Robert P. Goldman