[asdf-devel] Alternate default lisp system location

[Stelian Ionescu]

On Thu, 2014-03-13 at 11:34 -0500, Robert P. Goldman wrote:
> Stelian Ionescu wrote:
> > On Wed, 2014-03-12 at 23:30 -0400, Daniel Herring wrote:
> >> On Wed, 12 Mar 2014, Faré wrote:
> >>
> >>> Major changes like that happen less than once a year (ASDF 2 in 2010,
> >>> ASDF 3 in 2013, ASDF 3.1 soon in 2014), and while
> >>> backward-compatibility has always been a huge priority, improvements
> >>> sometimes do mean the recommended way of using ASDF changes, for the
> >>> better.
> >> For essential infrastructure like what ASDF claims to be, I expect major 
> >> changes to happen less than once every 5 to 10 years.
> > 
> > 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.


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


> I find this complaint to be quite unfair considering what actually goes
> on in the maintenance of ASDF.
> 
> > 
> > 
> >> 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" ?


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


> So who exactly is going to be participating in this RFC process?

I, for one.


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

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20140313/8bdeb521/attachment.sig>