[Cuis] Cuis base image reduced by 25%!

Bernhard Pieber bernhard at pieber.com
Wed Jun 26 13:09:55 CDT 2013


Hi Juan,

This is great! I very much like that direction as you know. ;-)

See more inline.

Am 26.06.2013 um 05:37 schrieb Juan Vuletich:
> If you update your image, all this code will be removed.
By "update your image" you mean loading the ChangeSets individually, right? There is no update command yet, right?

> If you download the updated image, it is no longer there. The packages themselves are also available at github, together with a txt file with a possible load order. I hope you'll find this more convenient when contributing code.
I think this makes contributing code much easier – for the extracted *.pck.st files. ;-) We can use pull requests for those packages with all the GitHub goodness which comes with them.

> There are several open questions, and I ask for your opinions and thoughts.
> 
> 1) The "official" Cuis image can have none/some/all of these preloaded.
This is a very good question. If I had to choose between "none" or "all" for the "official" image I would choose "all". You should definitely do development of Cuis in an image with all packages loaded. Otherwise, the external packages will break very fast. Do you agree? For the same reason I would encourage all developers to do developement in images with all packages loaded.

> We need to allow for clean unload of packages, but if there are no overrides, I think it is not a big deal.
If you can figure out the right unload order.
> I'm not sure what's best. Maybe all these packages (and maybe others) should be preloaded by default.

Of course, it would be best to provide both, "all" and "none". However, I would only do this by a fully automated build process. Otherwise it gets too much work fast. travis.ci anyone?

> 2) I'm starting to believe that it is best to have those packages that are kept up to date in the same git repo as the base image. This will make it very easy to know what is the proper snapshot of some package to be used with a particular Cuis update level.
I agree. For packages which are meant to be supported together with Cuis I believe this is the best approach.

> Besides, it makes sense to have a Cuis-Smalltalk organization. Therefore I created https://github.com/Cuis-Smalltalk , although I haven't saved anything there yet. I'd like to discuss with you the repositories to keep and their structure. I think that we might store there those packages that are preloaded, and those that are well maintained and actually used. But on the other hand, folks wanting to have better control of their code might prefer to host them in their own repositories...
> 
> After all this, https://github.com/jvuletich/Cuis should be deleted or marked as historic.
> 
> BTW, there are a few other fixes and enhancements in this last batch of updates. #reduceCuis now produces a 3.6Mb image with less than 80kLOC. Another tweak was to no longer kill the active changeset on image save. I hope this fits people who usually save the dev image at the end of the day.
> 
> Let's discuss and think of better ways to manage the Cuis codebase.
Yes, let's!

Cheers,
Bernhard





More information about the Cuis mailing list