[Cuis] Cuis base image reduced by 25%!

[H. Hirzel]

On 6/29/13, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 29 June 2013 21:45, Juan Vuletich <juan at jvuletich.org> 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

>> Does this make sense?


Yes, I think this is a usful approach some time in the future (2014?).
Learning about branches is not all that difficult and Angel had sent
some good links to the list in the past (last December or early this
year).

I think having different branches with will be very useful for people
coming up with their own variants of Cuis. For users it then would be
a matter of saying 'I want the image of Ken with his Unicode
additions'. And that would be a branch of the base image into which he
folds in the changes of the base image from time to time.

--Hannes



>>> ...
>>> Cheers,
>>> Bernhard
>>
>>
>> Cheers,
>> Juan Vuletich
>>
>> _______________________________________________
>> Cuis mailing list
>> Cuis at jvuletich.org
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>