https://forum.world.st/Cuis-base-image-reduced-by-25-tp4695195p4696407.html
> On 29 June 2013 21:45, Juan Vuletich <
[hidden email]> wrote:
>> 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
>
> Surely the natural approach to this in GitHub would be branches?
> "master" branch is your Stable, "devel" branch is your Development,
> and you fork off different branches for each release.
>
> frank
coming up with their own variants of Cuis. For users it then would be
additions'. And that would be a branch of the base image into which he