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
|