Dear Robert,
please consider merging these two branches before release: * renamed-bundle-op, fixes https://bugs.launchpad.net/asdf/+bug/1294018 * build-op, fixes https://bugs.launchpad.net/asdf/+bug/1293292
I can do the merging, if you want.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The fundamental class division in any society is not between rich and poor, or between farmers and city dwellers, but between tax payers and tax consumers. — David Boaz, CATO Institute
Faré wrote:
Dear Robert,
please consider merging these two branches before release:
- renamed-bundle-op, fixes https://bugs.launchpad.net/asdf/+bug/1294018
I'm a little uncomfortable with this, simply because I don't use the bundle operations, so I worry that I might be letting someone else in for trouble (although I don't see how).
Well, that's what pre-releases are for. How about you merge that, and then we can try to make a strong push for testing. I would guess that only people who are very involved with ASDF would use these operations so, as you say, changes should have minimal impact and be relatively easily identified.
- build-op, fixes https://bugs.launchpad.net/asdf/+bug/1293292
This one I would rather postpone until after the next release. Getting it into use would require even MORE modifications to the manual, and manual updates are already delaying everything.
The need for a short name isn't enough of a requirement to cause us to eagerly change the main entry point into ASDF loading.
: Faré
: Robert
please consider merging these two branches before release:
- renamed-bundle-op, fixes https://bugs.launchpad.net/asdf/+bug/1294018
I'm a little uncomfortable with this, simply because I don't use the bundle operations, so I worry that I might be letting someone else in for trouble (although I don't see how).
Well, that's what pre-releases are for. How about you merge that, and then we can try to make a strong push for testing. I would guess that only people who are very involved with ASDF would use these operations so, as you say, changes should have minimal impact and be relatively easily identified.
OK. I merged that branch, together with corresponding backfixes from my fare-3.1 branch.
This is a low-impact change, since I leave backward-compatibility stubs under the old names. People should only be affected if they defined they own methods on fasl-op or load-fasl-op, which I don't imagine anyone doing (and indeed isn't done in Quicklisp).
- build-op, fixes https://bugs.launchpad.net/asdf/+bug/1293292
This one I would rather postpone until after the next release. Getting it into use would require even MORE modifications to the manual, and manual updates are already delaying everything.
The need for a short name isn't enough of a requirement to cause us to eagerly change the main entry point into ASDF loading.
I'd like to convince you to let me merge in the branch anyway, for the following reasons:
* The ability to designate operations with strings is good, and makes defsystem-depends-on more useful, even without make * This is new functionality that doesn't interfere with anything, and therefore isn't a backward compatibility issue; then we can use #+asdf3.1 to depend on it. On the other hand, if we merge it after, we'll have to wait for #+asdf3.2 or so. * You don't actually have to modify the manual now (and/or I can do the update), much less make it the "main entry point" into ASDF loading (I'm backing away from that claim). But I would like the functionality in to be able to rely on it being present.
Regards,
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Any sufficiently advanced incompetence is indistinguishable from malice.
On Mon, Mar 24, 2014 at 6:30 PM, Faré fahree@gmail.com wrote:
- build-op, fixes https://bugs.launchpad.net/asdf/+bug/1293292
This one I would rather postpone until after the next release. Getting it into use would require even MORE modifications to the manual, and manual updates are already delaying everything.
The need for a short name isn't enough of a requirement to cause us to eagerly change the main entry point into ASDF loading.
I'd like to convince you to let me merge in the branch anyway, for the following reasons:
- The ability to designate operations with strings is good, and makes defsystem-depends-on more useful, even without make
- This is new functionality that doesn't interfere with anything, and therefore isn't a backward compatibility issue; then we can use #+asdf3.1 to depend on it. On the other hand, if we merge it after, we'll have to wait for #+asdf3.2 or so.
- You don't actually have to modify the manual now (and/or I can do the update), much less make it the "main entry point" into ASDF loading (I'm backing away from that claim). But I would like the functionality in to be able to rely on it being present.
branch build-op looks like it passes all tests, and in addition to the above, includes a refactoring of bundle.lisp to merge ecl and mkcl support and have mkcl follow the same image-op and program-op semantics as other implementations. I'd say it is ready to merge.
On the other hand, branch fare-3.1 (which also merges branch standard-syntax, and is experimental) has a weird weird failure on allegro that I cannot explain at all, in test-asdf.script: something is forcing a rebuild of the required-system.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Does artillery violate the natural rights of the target? I would say: the entire *purpose* of artillery is to violate the natural rights of the target. — Mencius Moldbug
Faré wrote:
On Mon, Mar 24, 2014 at 6:30 PM, Faré fahree@gmail.com wrote:
- build-op, fixes https://bugs.launchpad.net/asdf/+bug/1293292
This one I would rather postpone until after the next release. Getting it into use would require even MORE modifications to the manual, and manual updates are already delaying everything.
The need for a short name isn't enough of a requirement to cause us to eagerly change the main entry point into ASDF loading.
I'd like to convince you to let me merge in the branch anyway, for the following reasons:
- The ability to designate operations with strings is good, and makes defsystem-depends-on more useful, even without make
- This is new functionality that doesn't interfere with anything, and therefore isn't a backward compatibility issue; then we can use #+asdf3.1 to depend on it. On the other hand, if we merge it after, we'll have to wait for #+asdf3.2 or so.
- You don't actually have to modify the manual now (and/or I can do the update), much less make it the "main entry point" into ASDF loading (I'm backing away from that claim). But I would like the functionality in to be able to rely on it being present.
branch build-op looks like it passes all tests, and in addition to the above, includes a refactoring of bundle.lisp to merge ecl and mkcl support and have mkcl follow the same image-op and program-op semantics as other implementations. I'd say it is ready to merge.
Your strategy seems reasonable. How about we put into the manual a chapter, towards the end (an appendix, perhaps?) describing the EXPERIMENTAL build-op support, thus putting our users on alert that we reserve the right to change BUILD-OP in ways that break their code.
I don't want there to be a premature lock-in here.
thanks, r
Your strategy seems reasonable. How about we put into the manual a chapter, towards the end (an appendix, perhaps?) describing the EXPERIMENTAL build-op support, thus putting our users on alert that we reserve the right to change BUILD-OP in ways that break their code.
I don't want there to be a premature lock-in here.
Yes, I believe this is the way to go.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Faith, n: That quality which enables us to believe what we know to be untrue.
-
Faré -
Robert P. Goldman