"Andrew C. Greenberg" wrote:
> 
> I have found the debate about forking utterly tiring, and this will
> be my last post in that thread.  I would like to suggest that before
> slamming the status quo and arguing for what should be forked, that
> we first take stock of --and perhaps say thank you for-- what is
> already going on and in process.

I wouldn't be so dismissive of this thread... sure, parts of it were just people griping, but I thought Paul's 4-point list of requirements was at least specific enough to get some constructive discussion going (e.g. the replies from both you and Bijan).

We need more discussion on how feasible it might be to use the existing segmentation/environments work to get what Paul's looking for.  There hasn't been much of any discussion on this yet, partly because relatively few people know much about how the segmentation/environments stuff works.  (I certainly know very little.)  I agree that this needs to be examined more closely before splitting off a fork, or getting everyone behind the Stable Squeak fork.

> Has anyone been watching what has developed lately?  In the most
> recent changesets, we have had:
> 
> "Change Set:            SegmentingChanges
> Date:                   5 March 2001
> Author:                 Dan Ingalls
> 
> Several changes that make it possible to partition a current Squeak
> 3.1 image into a kernel image plus about a dozen segments.

This looks pretty cool.  Of course, a 4MB "kernel" is probably larger than what many would like to see... I assume it already includes Morphic.  But at least the infrastructure to do the segmentation is there, and perhaps the same sort of segmentation could also be done on this 4MB kernel to break it down into a smaller headless kernel and other components.  (I'm guessing there isn't any support for "prerequisites" yet, i.e. this segment requires this other segment plus the kernel in order to load?)

- Doug Way
  dway at riskmetrics.com