I smell a need for a CDR, c'nest pas? Tersely pecked on my iPad
On Mar 13, 2014, at 18:42, Faré <fah...@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. >
