Proposal to get to the triad

Daniel Vainsencher danielv at netvision.net.il
Sat Mar 8 12:16:23 UTC 2003


Basically, whatever our targets (and I think the kernel/core/base
division is a good one), the process is the same. It means establishing
limits within the image, through which dependencies go only one way -
down. Which means removing the references that go up.

There are two general tools we can use to do that -
1. Remove the evil uplinks by the root (breaking our integrated image on
the way)
2. Redeem them by refactoring (making our integrated image less direct)

Probably we'll want to mix the two, but unless we're willing to live in
a much less pleasant future Squeak, we have to be very aware of which
we're doing, and be very selective what we remove, so that we don't
throw out the baby with the tub water. 

What does this mean practically? I think as far as sharing the
refactorings goes, the idea of placing a removal script + a replacement
package on SM should work pretty well. However, we need to be careful
about the *contents* of both. The replacement package can't assume that
it is going back into it's old place, hooking itself into all those
longtime buddies that used to refer to it. It needs to hook up in
generic ways, such as the dynamic open menu, or the filelist services.

And those generic mechanisms have to be added in the removal script,
instead of the old hardcoded references. Just like before Celeste goes
out, it's references have been replaced with the open menu mechanism. It
isn't completely out yet, of course.

That's one of the things that people reviewing refactoring packages need
to be sensitive about - does this change create the hooks that allow the
package to be replaced cleanly? or does it leave a hole, making the
image broken, instead of just smaller?

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.

Daniel

Cees de Groot <cg at cdegroot.com> wrote:
> 
> --Boundary_(ID_H2bO2fJCYlXL7WfvoXGcIQ)
> Content-type: multipart/signed; boundary="=-OfX8HR6KZjQ4Sz82vn84";
>  protocol="application/pgp-signature"; micalg=pgp-sha1
> 
> 
> --=-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.
> 
> 
> 
> 
> --=-OfX8HR6KZjQ4Sz82vn84
> Content-Type: application/pgp-signature; name=signature.asc
> Content-Description: This is a digitally signed message part
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> 
> iD8DBQA+acAS8wOTf+CYnosRAvT2AJwIdcgoD6xUG8Ff9MvFzaIVuKkq1gCgk/5H
> ddV97bBUCgZ/XnQDB73NYrQ=
> =/uXN
> -----END PGP SIGNATURE-----
> 
> --=-OfX8HR6KZjQ4Sz82vn84--
> 
> 
> --Boundary_(ID_H2bO2fJCYlXL7WfvoXGcIQ)
> MIME-version: 1.0
> Content-type: text/plain; charset=us-ascii
> Content-transfer-encoding: 7BIT
> 
> 
> 
> --Boundary_(ID_H2bO2fJCYlXL7WfvoXGcIQ)--



More information about the Squeak-dev mailing list