Cees de Groot <cg at cdegroot.com> wrote:
> 
> --===============39979420065760668==
> Content-Type: multipart/signed; micalg=pgp-sha1;
> 	protocol="application/pgp-signature"; boundary="=-OfX8HR6KZjQ4Sz82vn84"
> 
> 
> --=-OfX8HR6KZjQ4Sz82vn84
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
> 
> 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').=20
> - 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.=20
> 
> 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.
> 
> 
> 


I consider this to be the way to go. To put the same message
into other words:


At 3.5 release time we basically have the two following artefacts 
to distribute



I) The 3.5 core image 
-------------------------

This includes a  build script to  load
packages from SqueakMap to get a base image.
(Only the script is there; but it has not been executed yet.)

The number of classes may be something between 1200
and 1500. Or less. But it is probably hard to do more
(i.e. having fewer classes in the core) in a 3.4 to 3.5 step.




II) The 3.5 base image
--------------------------

The base image is the 3.5 core image feature wise as 
described under I) plus the packages listed in the build script
already loaded.

Perhaps the build script is only applied virtually.
In that case it would mean that we take the 
3.4 image as is, with a stream of bug fixes applied to it.

The number of classes remains around 1800.
(cf. Squeak feature history
http://www.ira.uka.de/~marcus/swiki/minnow.cc.gatech.edu/squeak/2940.htm
l)



How to proceed?
-------------------

I think a consensus about this should be relatively easy
to obtain. What do you think?
Then "real work" as Diego Gomez Deck likes to put it could start .....



-- Hannes