Hi,

Just thinking a bit of a gentle way to get to the kernel,core,base triad
of images (it seems that there is general acceptance of the idea).

What we distribute now is called 'base'. I think that we have to do a
sweep down to 'kernel' first by stripping before we can think about
building up by adding. Here's a proposal:
- We release a duplicate of 'base' and call it 'core' ASAP. We apply
relevant removal scripts to 'core'. The tricky bit during this time will
tracking what bugfixes *not* to apply to 'core' because the component at
hand was removed. In 3.5, we probably will release an imperfect 'core',
but nevertheless this will be a first opportunity to try and see whether
we can easily bridge the small gap between 'core' and 'base' with a
configuration script (a sort of 'metapackage' in SqueakMap that sucks in
all the relevant stuff that differentiates 'base' from 'core'). 
- In subsequent releases, the gap will widen; at some point we will have
enough faith in the 'build' part so that 'core' becomes leading and
'base' is built up from there.
- At that point, 'core' is duplicated and the cycle repeats to get down
to 'kernel'. Probably because we're experienced by then, this will be
done progressively faster. 

IOW, I propose to make the 'split' (please don't read 'fork' here, just
the fact that we are going to distribute two images) ASAP and see what
happens - a gradual widening will give us ample time to learn what we
all need (in light of Diego's comments - act, not talk ;-)). For my
part, restrict ourselves on two or three easy-to-spot packages that'll
make the difference in 3.5 between 'core' and 'base' and just use that
difference to see what work is involved in doing all this in parallel.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030308/accac1bd/attachment.pgp