[asdf-devel] Alternate default lisp system location

[Mark Evenson]

I smell a need for a CDR, c'nest pas?

Tersely pecked on my iPad

On Mar 13, 2014, at 18:42, Faré <fahree at gmail.com> wrote:

>>>>> : dherring
>>>> : sionescu
>>> : rpgoldman
>> : sionescu
> 
>>>>> For essential infrastructure like what ASDF claims to be, I expect major
>>>>> changes to happen less than once every 5 to 10 years.
> Daniel, if you want changes only every 5 to 10 years, do like
> janderson: try an upgrade every 5 years, find that it breaks your code
> somehow and downgrade back to the old version without further
> investigation. Then maybe 10 years from now you'll get the system
> dependency bug fixed.
> 
>>>> You can expect whatever you want, but unless somebody is paid full-time
>>>> to work on ASDF, it's not going to happen.
>>> 
>>> Agreed.  Tell me: am I to piss our contributors off by refusing to
>>> accept their patches, in order to make happy the people who contribute
>>> only complaints? New features may simply be the price users pay to have
>>> bugs getting fixed.
>> 
>> The "force vs force-not" message is a good example. A feature was added
>> at the request of a user without considering all the use cases and now
>> we discover that it's poorly thought out. When you say "this has always
>> been my impression...", it means that nobody ever even wrote down a
>> rationale for that new feature so you don't *know*, you have
>> impressions.
> force and force-not were done well. The interaction between the two
> was not well thought out, but obviously no one relied on the
> interaction before force-not was implemented, so that was backward
> compatible, and the recent change keeps the previously useful uses
> working, so it is arguably, too.
> 
> It's not like my changes were done in secret. I did it and explained
> what I did, and even mentioned at the time I didn't understand which
> setting should take precedence over the other. I only apologize for
> not understanding then the objection by Robert, though he also didn't
> care enough to submit a patch, and no one else even complained.
> 
>>>>> The more backwards compatibility, the better.  Projects like glibc
>>>>> have developed significant infrastructure to enable transparent
>>>>> improvements (see the ABI compliance checker, DSO symbol versioning,
>>>>> etc.).
>>>> 
>>>> See above. That kind of backwards-compatibility is very difficult and
>>>> burdensome.
>>> 
>>> We spend a great deal of time maintaining backwards compatibility.
>>> Consider how much work was spent making the bug-fix coming from
>>> PREPARE-OP from breaking previous OPERATION subclasses.  Similarly, as
>>> someone who still uses ASDF:*CENTRAL-REGISTRY*, maintaining that is
>>> substantial backwards compatibility.
>> 
>> The backwards-compatibility is not complete, though. When we're talking
>> about glibc, we're talking about versioning functions and keeping the
>> old entry points bug-to-bug compatible for ever while the new version of
>> that function is simply an addition.
>> Issuing a warning that OPERATION is being directly subclassed is not
>> backwards-compatibility.
> We do care about backward compatibility, a lot. Yes, there are
> sometimes bugs in our backward-compatibility support. And then we
> painfully fix them, as in the case of OPERATION above. Are we perfect?
> No. Do we have symbol versioning for backwarder compatibility? No. The
> libc has additional issues and solutions because it's all about binary
> compatibility. We do not offer binary compatibility. We offer source
> compatibility. We consider binary compatibility is backward.
> 
>>>>> Every breaking change inflicts cost on a fraction of the existing
>>>>> userbase, in exchange for some proposed benefit to future users.  Every
>>>>> time I have to debug breakage and change something or redesign my workflow
>>>>> to maintain existing capability, it encourages me to explore other, more
>>>>> stable or better designed options...
>>>>> 
>>>>> Sometimes "good ideas" fade after a month or two of reflection.  Some
>>>>> survive the test because the benefit truly outweighs the cost.  When that
>>>>> is the case, it is often helps to give the community time to prepare and
>>>>> minimize the number of times the community must change.  So propose the
>>>>> change, allow a long RFC window, allow users to obtain test
>>>>> implementations (while still promoting the stable branch), wait a while
>>>>> for several changes to collect before pushing them into major new
>>>>> releases, etc.
>>>> 
>>>> I agree that an RFC-like process would be useful, instead of jumping in
>>>> and implementing new features, as long as it's not too lengthy.
>>> 
>>> It has, in fact, been a long time since ASDF's last release, October
>>> 2013.  During that time, there have been a very large number of tagged
>>> versions available to the community.
>>> 
>>> I don't think that this community can afford the time, nor can it muster
>>> the interest, to deal with such an RFC process.
>> 
>> What "community" ?
> If someone wants a RFC process, he's welcome to write a specification
> for ASDF that all the currently documented or undocumented features
> implicitly relied upon by every piece of software in Quicklisp, and
> develop an independent reimplementation of ASDF based on that
> specification.
> 
> Now I'll be the one laughing, and even more so if the RFC gets to also
> specify all the backward compatibility "features" of ASDF.
> 
> For a start, I propose you try to RFCize quick-build, with which
> asdf-package-system is compatible — here you've already got two
> independent implementations of the same thing (three, if you count
> faslpath, after changing the separator from "." to "/"), and the
> implementations are both around a hundred lines of code only. Only the
> root registration protocols differ. If you can't standardize that,
> don't even dream of standardizing the rest of ASDF.
> 
>>> Furthermore, I don't find people stumbling over each other to install
>>> ASDF prereleases from git and report bugs they find.
>> 
>> I'm not talking about mundane compatibility problems with pathnames, but
>> design choices that will affect everybody that uses ASDF in production,
>> for deployments and writes ASDF extensions. Most of the time there isn't
>> even an announcement that a new feature was added, like a new keyarg to
>> defsystem, etc...
> Every release comes with release notes that mention changes to the API.
> I haven't announced changes with every commit, because that would be verbose,
> and people who're interested can already read the git log.
> 
> Design choices are being discussed here, but only the small details
> lead to bikeshedding discussions like the recent flurry of messages.
> When there's a serious design choice, either no one replies, or it's a
> discussion between Robert and I, usually, though I readily admit you
> (Stelian) have sometimes contributed key ideas.
> 
>>> And who is going to be testing these prereleases?  We have quite a
>>> small community of testers, to whom I am very, very grateful.
>> 
>> I've done a lot of testing on my own stuff and reported quite a lot of
>> bugs to Faré in the past.
> Yes, and I am grateful to you (Stelian), who indeed in IRC (and live!
> and launchpad) discussions contributed a lot to ASDF.
> 
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> The highest of minds / Often have built for themselves / The tallest of jails.
>