Separate update stream for each layer? (was Re: Proposal to get to the triad)

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


(Sorry, I meant to reply to this thread earlier...)

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

This is more or less what I pictured would happen during the 3.6 
release.

For the final 3.6 release, I'm pretty sure we want two images 
available:  The full kitchensink (base) image, and the smaller 
developer (core) image (which would be considerably pared down, though 
there may still be some extra non-developer stuff in there).

However, in your original message in this thread you suggested a split 
between the images, such that we would need to track which bugfixes 
should not be applied to the developer/core image because a package had 
already been removed.  This means that you're actively maintaining both 
images through the alpha cycle, and that you'd probably need an update 
stream for each image.  (Is this what you were suggesting?)

My thought is that having the two update streams would be rather 
complicated to manage.  (Speaking from the update stream manager's 
point of view. ;-) )  My assumption was that we would not have an 
update stream for the kitchensink image; the update stream would only 
follow the shrinking image.  So there would really only be one "active" 
alpha image, and package removals would be performed as updates.

However, we would still have the core -> base (er, developer -> 
kitchensink) "re-grow" script that you mention.  This could be 
continually maintained through the alpha cycle such that anyone who 
wanted a current kitchensink alpha image could start with the shrunken 
(developer) alpha image and apply the script.  Sure, the script and the 
resulting kitchensink image might be buggy during the alpha stage, but 
by the time 3.6 went final, the serious bugs would be ironed out, and 
we would have a reasonably solid 3.6 kitchensink release to go along 
with the smaller developer image.

(If a bug appeared in a package that had been removed (such as 
Celeste), the only place the bug would be fixed is in the Celeste 
package on SqueakMap.  The developer -> kitchensink script would load 
the latest Celeste package which would include the fix.)

Would this be too great an inconvenience for people who want to stay in 
the kitchensink image during the alpha stage?  I believe the phrase 
"tough cookies" applies here. ;-)  But seriously, I'm not sure that two 
parallel update streams would be workable.

Besides, much of the purpose of the kitchensink image is to provide a 
feature-filled environment for newbies to try out.  Newbies will 
generally be using the final releases, not alpha/beta/gamma.

Or perhaps there are third and fourth alternatives that I'm not 
considering, which might be workable...

- Doug Way



More information about the Squeak-dev mailing list