[Cuis] Cuis base image reduced by 25%!

[Juan Vuletich]

Hi Bernhard,

(inline and abridged)

On 26/06/2013 03:09 p.m., Bernhard Pieber wrote:
> 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?

Right and right. There is no "update command" yet. We'd add it sometime.

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

Yes! I'd love to see pull requests used.

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

Yes, indeed.

> For the same reason I would encourage all developers to do developement in images with all packages loaded.

Agreed. The image with packages unloaded would be better, for example, 
for people learning about the system, or with specific needs.

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

Ken's suggestion, "Features" should help with that.

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

Well, maybe there's no need to provide the "none" image on each update, 
but only on "official version release", if this concept still makes 
sense... Thinking aloud now. I think that the Cuis-Smalltalk GitHub 
organization could have 3 repositories:

     Cuis-Smalltalk/Stable : Committed just a few times a year. Contains 
only reasonable tested image(with packages), image(without any 
packages), packages. Each commit is a Cuis version.revision number. All 
packages should load and run reasonably well. If we're freezing a 
release, and some package is not updated, and is incompatible with the 
release, it is removed from here (i.e. it is "not supported" for this 
release).

     Cuis-Smalltalk/Development : Contains more frequent commits of 
image(with selected / all packages preloaded), supported packages (to 
ease diffing in the web browser), and update stream (numbered change 
sets). Might occasionally be broken, or include incomplete stuff. For 
people who want the latest, and can cope with this. For example, package 
developers, and people contributing code to the base image. Packages are 
only removed from here when abandoned (i.e. they are 
broken/incompatible, and nobody is working on fixing them anymore).

     Cuis-Smalltalk/Historic : One zip file for each release

Does this make sense?

> ...
> Cheers,
> Bernhard

Cheers,
Juan Vuletich