On Sun, 30 Jan 2005 10:20:55 -0000, Peter Crowther <Peter at ozzard.org>  
wrote:

> -- another way --

Hear, hear! (mostly. There are quite a number of nits in your story I'd  
like to pick, but I'm not going to do that at this moment)

BTW - I'm thinking that we could decide to "just do it". Cause major  
breakage in, say, a version we call 3.14159... by starting with one of the  
small images (I got a very nice image from Edgar De Cleene - networking,  
(MVC) dev tools are there, it's 2Mb big and based on 3.6. Shouldn't be to  
hard to roll this core code (lots of MVC tool code that hasn't been  
changed anyway between 3.6 and now, I think) forward to the current state.

It's not a super-duper minimal core (which I, personally, tend to define  
as "the minimal Squeak system that can bootstrap itself in one way or  
another into something more useful" - Craig's work fits that definition  
nicely, of course), but it is a whole lot better than what we've got now  
and could be done immediately, just by deciding to do it. Probably by  
(mentally) splitting it up, internally, in 'core', 'dev' and 'networking',  
you'd have a 'core' that's quite close to what you want at the end.

The efforts to make a really minimal Squeak image could all continue, but  
by kicking out 90% of the code right now we'd be 95% there, not?

And, yes, I know that I'm conveniently ignoring a whole slew of issues.  
But by Just Doing It, we could actually attempt to tackle these issues  
instead of constantly debating them. It'd be a whole lot easier to have  
lots of package and observe how they interact and depend and finding ways  
of dealing with that, than theorizing about it. But then, I'm a coder, not  
a researcher.

(re breakage - I just realized that it should be possible to use the RB  
rewriting stuff with thisContext sender to actually rewrite methods that  
call obsolete stuff and send the maintainer of the package an  
auto-generated patch. Now that'd be an elegant tool for dealing with bit  
rot ;)).