Jerome Peace wrote:
> My point is that 9 out of ten of the "smartest and
> most efficient Squeakers". choose to develop and
> express their vision, focus, with execution using
> update streams.

Not in my experience. Except for the OLPC team I don't know any other 
serious development effort that is based on change sets (if you disagree 
name a few). And mostly I would claim for OLPC this is due to historical 
reasons, e.g., we've always used updates for eToys and there isn't any 
compelling reason to change that, in particular considering that the 
people involved have exhaustive experience with managing update streams.

> Process has a direct relationship to results.

That is certainly true.

> Anyone can update and save a current OPLC system in a
> handful of minutes.

Yes, that is also true and one of the powerful things about incremental 
updates. On the other hand, try to port changes from the OLPC image to 
Squeak 3.9 and see how that goes. You'll go wildly fishing through a 
large number of changes desperately trying to figure out what got 
changed where and which effect it might have on other ends of the system 
and how (and if) it depends on changes done three months ago. Been 
there, done that. Monticello makes that kind of stuff really easy - if 
we need fixes in Qwaq's internal version of some package we simply do 
them and at some point we merely merge them back into the public version 
and we're done. We can always look what has changed where, when and how.

In any case, those are different trade-offs for different styles of work 
and different goals. If you want to make progress quickly, updates and 
change sets might be for you. If you want to be able to reflect about 
the changes in an organized manner and move code between various images 
and versions, Monticello is pretty much the only choice.

Another way to look at the above is where you put the time - updates are 
mostly "back-end loaded" as they will require very significant work if 
you ever need to do anything with the code after it is out, whereas 
Monticello is more "front-end loaded", requiring to put more thought in 
before you do things. That means Monticello is intrinsically slower to 
develop initially but also more stable in the long-term. Both of these 
observations match exactly my experience with both development styles.

But by the end of the day I'd still insist that the main difference is 
not in those tools but rather in the people working with them.

Cheers,
   - Andreas