Dear Edgar,
> The current release model is Ralph model.
> No scripts, no external mumbo jumbo.
>   
The external "mumbo jumbo" as you describe it is only part of the story.

The "external mumbo jumbo" bit of the process is external for those 
users who are starting from different starting points. A KernelImage or 
a 3.7 image does not have a ReleaseBuilderFor3dot11 class in it, so 
running ReleaseBuilderFor3dot11 unloadTraits will not work for those 
users, particularly since it has not be designed to work for those 
users. To write a ReleaseBuilderFor3dot11 unloadTraits method adopts 
what I think is a short sighted approach to the future of squeak, 
Matthew and I are trying to promote something more dynamic and interesting.

The "external mumbo jumbo" provides a collecting point for ideas, and 
the ability to pick and mix components in order to build the image you 
want in order to test ideas.

Case Study:

When I wrote Rio initially it relied upon numerous kernel-level changes. 
This was a problem because most of my potential users would load it and 
find that they didn't have the required dependencies. So I have a choice 
to make, either,

1) write new code for the future that is only usable by users with all 
of my latest bug fixes in the very latest image, (i.e. my use only) or
2) throttle back on innovations in order to provide a package which uses 
a lowest common denominator, for everyone to be able to use it

Another example, Monticello, either

1) move MC forward only for users of the latest greatest squeak image, or
2) Make MC use the lowest common denominator code.

This is difficult to actually achieve since I am using the latest image 
to work in. So I have to keep testing MC in 3.7 for backwards 
compatibility, one might as well continue to use 3.7, but then what 
happens if something in a later image becomes deprecated (e.g. 
Collection-upTo:) in this case you have to continually test for forwards 
compatibility.

We are aiming to provide an alternative to the two options above. To 
move to a model where a package such as MC can be loaded and tested in 
ALL images automatically. At the same time enabling the differences 
between starting point images to be factored out of the main MC 
package.  This loading and testing tool is the tool that I have 
christened "Bob".

So... The "external mumbo jumbo" as you call it is external for a 
reason, there is no need for all of it to remain external. At some point 
it is able to hand over processing to internal code.

Sake/Packages does this. The "external mumbo jumbo" loads the 
appropriate "internal mumbo jumbo" for the users image, be it, etoys2.3 
from OLPC, or Croquet, 3.7 or 3.10. The internal mumbo jumbo defines all 
of the packages available, how to load them, and unload them. Loading 
and unloading can capture any bug fixes needed for any individual 
package. All dependencies are also captured, using a code based model, 
built upon the Sake scaffolding.

And then there is Sake/Tasks (work in progress) , again the "external 
mumbo jumbo" loads the appropriate "internal mumbo jumbo" for the image 
the user is using. The Sake/Tasks equivalent of your ReleaseBuilder 
unloadTraits, would be.

TasksSqueak311 unloadTraits run "or perhaps"
TasksCommon unloadTraits run.

Being a task, unlike "ReleaseBuilder unloadTraits", it is not designed  
to be run exclusively in the context of a single carefully constructed 
realease building script, it is designed to be more intelligent than 
that, to be a bit more self aware, so that any user could decide at any 
point no matter what image they have... I dont want traits any more, 
lets unload them now.

As a task it doesnt run if it has been run already, it doesnt run if it 
is not needed, and it can define pre-requisite checks,  and may have 
dependencies upon other tasks. As a task it also comes with Tracing and 
Logging tools for debugging what is happening when and where.
> As example I resurrect ReleaseBuilder , used in 3.8 and older releases.
> Bert at the time we start advice about how do this.
> And Ralph says no Doits, no weird things.
>
> So if we wish unload Traits, we must have a #unloadTraits as we have #
> unloadMorphicClasses and #unloadSome in ReleaseBuilderFor3dot10.
>
> In ReleaseBuilderFor3dot11 we have #unloadSomeMore2 ,#unloadSomeMore3 and #
> prepareforUnloadBookMorphandFriends #prepareforUnloadEtoys #
> prepareforUnloadNebraska
>   
All fine and good, but basic non-task methods lack any formalization for 
pre-flight checks, dependencies or logging and tracing. They are one hit 
wonders. You could argue, who cares, you only want to run them once. But 
in a bigger more diverse release team trying out different ideas in 
different images, in different scenarios, packaging this knowledge as a 
Task makes it more useful overall.
> Keep in mind in the future we should converge to Pavel works
> (MinimalMorphic) to Craig Spoon or to Juan Vuletich Morphic 3.0, the three
> forks I have as example of how I wish future Squeak should be.
>
>   
As you state here, there are several options as to the way squeak could 
or should go. We as a community are not yet used to working with this 
level of ambiguity.

You want to push on ahead with 3.11, while the rest of us see that as 
dependent upon more supporting tools such as I have described above. If 
you want to rush on ahead of us then fine go ahead, but you actually end 
up making our job harder, since it is more difficult to track 4 fixed 
targets (3.7, 3.8, 3.9, 3.10) and 5 moving targets (OLPC, Croquet, 
Sophie, 3.11, Pharo), than 4 fixed targets and only 4 moving targets.

Furthermore this will result in you taking on ownership of the 3.11 
project and leaving us the rest of us behind with no image of our own in 
which to showcase these ideas, you will force us to fork 3.10, and for 
goodness sake we dont need another fork just yet. 
6 months down the line you will be complaining about how you have had to 
do all of the work yourself and that no one supported your effort 
sufficiently to your liking.
> Now people say FunSqueak should be next full release, very happy with that.
>
> In Smalltalks 2007 I show all the FunSqueak, six months ago...
>
> Soon , if Lord wish, I become 59.
>   
I am sure the Lord is fine with that idea.
> So to old to waste my time.
>   
Then dont waste your time, get with the programme!
> Or Board say I could do 3.11 and people liking to work on this with me start
> to Smalltalk...
>
> Or we could continue JustTalking.
>   
As I have said before, we have not been JustTalking, Matthew for one has 
been working hard, I have been dealing with personal issues for a bit, 
and trying to pay the bills. There has been significant progress made if 
you just open your eyes to see it.
> Cheers.
>
> Edgar
>
>   
Best regards

Keith
>
>