Once and only once - code that affects packages should be distributed in no other way than by being in the package.
This important for two reasons - 1. The package owner really should be the only one that decides about code that goes in his package. 2. If packages depend on active Harvesting of all their stuff, that slows down the maintainance of base itself, and the evolution of all packages. The opposite of what we want.
Part of this is removing concerns from the Harvesters. The maximum they should worry about packages is that when packages are updated that affect a certain image brand (base, full), the maintainer of the image should have the option of making the package update itself. Of course, this can be done easily if SM in the image, which is not a problem for Base and Full.
Daniel
John M McIntosh johnmci@smalltalkconsulting.com wrote:
On Thursday, May 8, 2003, at 04:22 AM, goran.hultgren@bluefish.se wrote:
But the update stream is only used for code not in packages. It can only "expect" an image that doesn't have SM. Aargh. My head spins.
Need to think more...
Well any way to change the update stream logic to consider packages. Then the update stream could update packages if they are installed, otherwise they get skipped. Later if you load said package and rerun the update, it might go back and re-apply updates as needed based on which packages are now loaded?
--
=== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
So in other words, I think we should be able to go ahead and add SqueakMap to the current image? It will certainly be part of the Basic image, and would probably toward the end of the list of items removed from the Minimal image (after most development tools, Morphic, MVC, etc., are already removed).
We will simply "promise" not to use the main update stream to change code that resides in packages. The only exception would be SqueakMap itself, which I guess also happens to be a package. But I don't think that's a major problem... yes, the update stream may include major upgrades to SM (such as SM 1.1) which simply overwrites the old package in the image.
(Then there's Andreas' new stuff which supports update streams on individual packages, which I haven't looked at closely yet... I'm not sure if that would make a big difference for this particular case.)
- Doug Way
On Friday, May 9, 2003, at 10:21 AM, Daniel Vainsencher wrote:
Once and only once - code that affects packages should be distributed in no other way than by being in the package.
This important for two reasons -
- The package owner really should be the only one that decides about
code that goes in his package. 2. If packages depend on active Harvesting of all their stuff, that slows down the maintainance of base itself, and the evolution of all packages. The opposite of what we want.
Part of this is removing concerns from the Harvesters. The maximum they should worry about packages is that when packages are updated that affect a certain image brand (base, full), the maintainer of the image should have the option of making the package update itself. Of course, this can be done easily if SM in the image, which is not a problem for Base and Full.
Daniel
John M McIntosh johnmci@smalltalkconsulting.com wrote:
On Thursday, May 8, 2003, at 04:22 AM, goran.hultgren@bluefish.se wrote:
But the update stream is only used for code not in packages. It can only "expect" an image that doesn't have SM. Aargh. My head spins.
Need to think more...
Well any way to change the update stream logic to consider packages. Then the update stream could update packages if they are installed, otherwise they get skipped. Later if you load said package and rerun the update, it might go back and re-apply updates as needed based on which packages are now loaded?
--
==
John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ====================================================================== == ===
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Hi!
Doug Way dway@riskmetrics.com wrote:
So in other words, I think we should be able to go ahead and add SqueakMap to the current image? It will certainly be part of the Basic image, and would probably toward the end of the list of items removed from the Minimal image (after most development tools, Morphic, MVC, etc., are already removed).
We will simply "promise" not to use the main update stream to change code that resides in packages. The only exception would be SqueakMap itself, which I guess also happens to be a package. But I don't think that's a major problem... yes, the update stream may include major upgrades to SM (such as SM 1.1) which simply overwrites the old package in the image.
Ok, some reasoning here:
1. SM is a package. As it should be. As all things will be. 2. Basic should include SM and a bunch of other "tools" too IMHO. Like DVS. Still as installed packages of course. 3. The current image is transforming itself into Minimal. We said earlier that it is transforming itself into Basic but I don't agree. For example, it doesn't contain SM nor DVS so... :-) By definition it is in some ways actually "smaller" than Basic! 4. I repeat the above just to make sure we agree: The current image is transforming itself towards Minimal. The updatestream is thus attached to Minimal. 5. So what we have today is a large Basic-looking *Minimal* that still includes many wannabe-packages BUT ALSO does not include SM, DVS, SAR etc. 4. When we release 3.6 we should have: a) a sortof Minimal image. A very large one, but still going towards Minimal. b) a loadscript that can bring this image upto Basic. c) another loadscript that can bring Minimal upto Full. It could even be "smart" so that it can be applied to a Basic image too. 5. But on the road towards 4abc - what does the image contain that we are working in? We don't want to work inside Minimal! We want to have Basic.
Aha. So the 3.6a image I have sitting on my harddrive with a updatestream connected to - what IS IT? My conclusion: It is the Minimal image with *packages installed* so that it looks like the Basic image that 4b above will produce.
Ok, back to the issue at hand: SM. And IMHO DVS, SAR and Package Loader. And perhaps one or two more I am forgetting right now. My reasoning above may sound like I don't want to introduce SM into the image - but in fact I do. :-) But not as "just another changeset". I want them *installed as packages*.
What this means in practice is the following:
We should issue updates through the update stream that installs these puppies using SM! The SM bootstrap changeset (the one that you get if you do the "Open packag loader") makes it look like SM itself was installed through SM (though of course it wasn't).
I know that Scott Wallace earlier argumented to put SM into the image - and I strongly objected. I still object to simply "filing it in" just like *any changeset*.
In short - we can issue an update that simply runs the bootstrap. We can keep the bootstrap code in place for a while.
(Then there's Andreas' new stuff which supports update streams on individual packages, which I haven't looked at closely yet... I'm not sure if that would make a big difference for this particular case.)
I don't think so. I may try it out but I can't see how they have anything to do with us just yet. That package could OTOH be a candidate for Basic of course - just like DVS, SAR etc.
Phew - so what do you all say? Does my analysis above sound reasonable? I find it strange that it seems so hard to define what things are - we really are creatures of habit. Hard to let go! :-)
- Doug Way
regards, Göran
squeakfoundation@lists.squeakfoundation.org
-
Daniel Vainsencher -
Doug Way -
goran.krampe＠bluefish.se