[asdf-devel] Alternate default lisp system location

[Faré]

>>>>: 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.