I agree with what igor said.
Now give us or join to build one of these items
- a fast way to load package (fuel but there is still some work)
- a spec for managing packages (metacello)
- a set of tests (we have some but we need more)
- a bootstrap (with have a mini image so this could be ok).
and we will build and not carve and we will maintain a full set of
packages.
So we are getting there but this is not good to not test/use all day long what
we release.
So this will be like that for a moment but our goal is what I mention above:
rebuilding from scratch all the pieces
all the time and fast and we will get there.
Stef
On Aug 16, 2011, at 8:21 PM, Torsten Bergmann wrote:
> Stef/Mariano wrote:
>>> So now we are including several packages in the image so that we do not
>>> have two images.
>>>
>>> I am not against this, but I think it is a must to provide a
>>> #shrinkToPharoCore and a hudson associated to that.
>>
>> yes good idea
>
> Interesting (nearly silent) switch in the way we build Pharo(core).
>
>
> With one "Core" and several distro packages like "pharo-dev", "seaside"
> we once switched to the model anyone is used to in other technology sectors:
> building a house or a machine by stacking up/assembling small pieces.
> So we had a "start with a base/core and load what you need" model
> similar to Linux kernel and distros. So you could pick up what you need.
>
> I thought this is the right model - since we can cleanly load
> and keep images small while checking if something is running
> after loading with CI/Hudson.
>
> But now we extract the kernel/core from the (bloated?) distro.
>
> For whatever reason I often see this tradition of "Stone carving" in
> Smalltalk. One has a large image and strips it down for deployment
> (throw out what you do not need). Often you get problems in unloading/
> clean loading again. Classes are referenced across the image without
> checking the load order, ...
>
>
> Mmmmhhh ... who shares the same feeling that this is not a good idea!
> When there is a #shrinkToPharoCore then there is a pharo core image
> anyway - so we always have two images. And we have to test it and
> check if packages load cleanly anyway (using CI).
>
> Can you at least ellaborate what led to this step? Is PharoKernel
> the new Pharo Core? Will we test reloading after shrinking? ...
>
> Thx
> T.
>
>
>
>
>
>
>
>
> --
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
>
