Shrinking alpha image (was Re: Proposal to get to the triad)

Doug Way dway at riskmetrics.com
Wed Mar 19 06:19:43 UTC 2003


On Saturday, March 8, 2003, at 11:40 PM, Daniel Vainsencher wrote:

> There're a good reason I advocate delaying the split. We don't yet have
> the deployed technology to make it trivial (SM dependencies), and it
> make the workload larger for the person at the wrong side of the funnel
> - Doug.
>
> We can't afford it. But we will soon, and we need to be ready, by 
> having
> unload scripts.
>
> As you say, it is useful to create and test an image "shrunk" to base,
> what we can't afford yet is to make it a release deliverable, with an
> update stream and so forth.
>
> But it would really be useful for someone to create an informal script
> as you describe, to make it easier for people to test out the "core as
> it will be".

Okay, it sounds like this is a different alternative to what Cees or I 
mentioned.  You'd maintain a kitchensink image through the 3.6alpha 
cycle, and also maintain a shrinking script.  Then, after SM 
dependencies were available, you could go ahead and do the "split".

The thing I like about having a shrinking alpha image + a "re-grow" 
script is that I don't think we'd really need SM dependencies or even 
SM 1.1 (versions) to get started.  Ideally, the re-grow script would 
simply be an ordered list of SM packages to install.  Hm, I guess one 
problem would be that if you wanted to re-grow an older alpha image, 
you would have no history of previous SM package versions, so perhaps 
you do need SM 1.1 at least.  Perhaps the SM-version issues are the 
same with each approach.  The main advantage of the shrinking approach 
is that the re-grow script should be easier to maintain than a 
shrinking script, over the long term.

(I suppose that, either way, the single "master" image update stream 
will eventually be going away, so perhaps it doesn't matter that much 
in the scheme of things whether the update stream stays at the 
kitchensink level until it's no longer needed, or whether it follows 
the shrinking path to its demise. ;-) )

- Doug Way


> Daniel
>
> Cees de Groot <cg at cdegroot.com> wrote:
>>
>> On Sat, 2003-03-08 at 13:16, Daniel Vainsencher wrote:
>>> While making the actual split into kernel/core/base will have to 
>>> wait a
>>> little until we have dependencies, we can start reviewing the 
>>> existing
>>> removal scripts now, that's the real measure of our progress.
>>> =20
>> I agree with your description of what needs to be done. However, I 
>> think
>> it is useful to start applying these removal scripts to a 'core' image
>> right away. The script that moves core -> base will be small, and it 
>> is
>> quite feasible to keep it as a single manual script for the coming 
>> time.
>> By the time that gets unfeasible, we'll have a largish script 
>> containing
>> a lot of stuff we learnt about how to load a number of unrelated
>> packages. This will provide valuable input to what is needed in the 
>> area
>> of dependency mechanisms, so that when refactoring the script, we'll
>> land at a) practical dependencies, and b) have a mini-package that
>> brings core->base ideally just by listing dependencies).
>>
>> Summary: removal/replacement pairs that have gotten the necessary
>> reviews are immediately applied to the core/base split, by removing 
>> the
>> package from 'core' and doing an appropriate update of the 
>> (monolithic)
>> core->base script.
>>



More information about the Squeak-dev mailing list