>>
>> The bootstrap always loads the essential code loading tools, and  
>> absolutely
>> essential fixes in a primitive manner in the image commandline  
>> startUp
>> script. This is essential because the code loading tools can never  
>> reliably
>> load the code loading tools.
>
> Maybe a clone of the loading tools could.

Yes indeed, we would like to have a poor-mans namespace solution of  
some kind even for legacy images. This can be done via grep/awk on the  
source file easily enough.

> Thanks for taking time to explain your model.
> The main problem you will face is that you currently don't control the
> fix point neither of trunk, nor of Pharo, maybe not even of Cuis.

But I don't care about building stuff in pharo or trunk. I am only  
ripping stuff out of them, and tracking changes there, so I only need  
my tools to load that is all, just 3/4 significant classes.

Cuis on the other hand uses a nice simple single update stream that I  
can see. (just like Edgar is wishing for again)

Juan has promised to stick to the kernel of the image and not be a  
control freak about the whole thing, he is not imposing any tools on  
me and he is not putting up any barriers to what I can do in the  
image. Best of all he is not the bottleneck in the process. I dont  
have to persuade him to incorporate my fixes, because he is happy  
without them, and I am happy with them.

> The second is to convince squeakers to adopt new model and new tools.

I don't want to convince squeakers, all I want is control of the image  
back to do a job.

However, anyone who does join us, on  
setools at lists.squeakfoundation.org , or in irc #cuis I can promise you  
control of your own image, and I can promise you you can fork as much  
as you need to, but if you use this toolset you will not get left  
behind because the forum and tools for exchange of innovations between  
forks is in place.

No image ever gets "released" and given to you to cope with. Rather  
completed stable features get released. You build the image you want  
by picking the stable features you want.

No image you build ever stops being supported, although I use cuis as  
a starting point, you can pick your own starting point. Every  
innovation will be planned, documented, crafted and published  
separately for integration.

not a bad start for a manifesto.

Keith