My prior comments should have included the information that I have 
been using Package Loader for all package/update installations and 
that the observations have held going back some months as well as 
recently for 3.6 (5429) and 3.7a (up to and including 5816). I do 
most of my work on OS X but also check against Windows (mostly XP). 
In spite of my whining I am encouraged the the issues have manifested 
themselves EXACTLY the same on OS X and Windows [I definitely can't 
say the same about Java ;)].

>It would be very useful to know which packages you are having trouble with.

The most recent examples were seeming interaction issues involving 
Whisker (0.93) BrowseUnit (1.0.3) and the Whisker (0.93->1.0) update. 
After installing the Whisker update I found that Whisker would 
generate a MessageNotUnderstood anytime I clicked into a method 
editing pane to the effect of

     MethodSubstitute(Object)>>doesNotUnderstand: #updateCodePanelIfNeeded
     ...

Starting from scratch and using my install sequence of

     Install updates for base installed packages
         MCInstaller (8->10)
         Benchmarks (2->3) [requires Monticello install and update]
         Monticello (144->146)
         Balloons 3D (1.0.3)

     Install my base set of development packages
         Refactoring Browser and related tools (->1.0.3)
         Whisker Browser (->1.0)
         BrowseUnit (->3.1)
         Whisker++ (->++)
         ... [plenty mo' stuff after this :)]

resulted in a once again stable image.

A couple of other recent problems have included the Units, Chronology 
and Completion Enhancements packages (last two of which I've stopped 
using for the time being because my cargo culture approach wasn't 
finding a successful package loading sequence).

Out of a combination of shear laziness and not wanting to be lobbing 
"stuff's not working" messages to the list I haven't been keeping a 
log of the specifics for well over a couple of months since finding 
that the "from scratch" method gets me to usable results. The Squeak 
Community has and is doing a tremendous job and I have been very shy 
about wasting other people's time.

>   One of the goals of Monticello is to provide exactly that kind of 
>in-place update.

That had been my understanding from reading about Monticello but was 
in no position to evaluate it or how it is being used (or not). I 
suppose I should work on grokking it from the get go for my own work 
so that I have a leg up on some of these issues. I'm very open to the 
idea that I'm whining about something effectively already handled.

>If you're updating packages distributed as changesets, or don't have 
>Monticello installed, then, yes, you're likely to have problems 
>unless the author has been very careful.

After a very informal survey of packages it seems Monticello hasn't 
yet become the majority tool w/methods. I've read some threads in the 
last couple of weeks seeming to touch on package metadata concepts 
some of this stuff may already be on a path to fruition. Not being 
able to see dates in Package Loader I couldn't tell if most of the 
issues are caused by "stale" packages. I have noticed that the Fresh 
Meat page doesn't seem to have entries for all changes so didn't find 
that a reliable source regarding "staleness."

>Even using Monticello, there can still be issues with migration of 
>existing instances; it would be interesting to try to figure out how 
>many of the problems you're running into are of that kind, and 
>whether they could reasonably have been fixed.

I'm willing to get back on the "tracking horse" to collect data but 
don't feel qualified/equipped to do useful analysis for the 
community. I'd be happy to send data to someone "off list" in the 
interest of avoiding the "lobbing effect" and not creating an 
impression of undue criticism or nit picking of generous 
contributions. I also know there is a 3.7b push in the pipe and that 
resources are more constrained than usual. In any case, I'm willing 
to chip in my meager effort in whatever way might be beneficial.

>   It may be useful to eventually build some kind of explicit 
>migration management into Monticello.

The specifics of Monticello aside, it seems to me that configuration 
management of [Squeak] Smalltalk is an important set of issues to 
more deliberately attack. I wholeheartedly agree with Alan Kay's 
statements about how little progress has been made compared to 
Smalltalk. However, I do believe that Smalltalk could benefit from 
some of the configuration management progress made in worlds of the 
"lesser" tools/languages. My question would be whether Monticello 
should be configured item repository with configuration deployment 
capabilities, or whether configuration deployment should be a 
separate beastie. In any event, I can't help but believe Smalltalk is 
the place to create the most elegant and effective solutions for this 
particular set of vexing problems.

-- 
----------------------------------------------------------------------
Anthony Anton        3800 243rd Place SE          Phone:  425-313-1024
                      Issaquah, WA 98029           Cell:   425-444-3084
Concept Systems      agantoniii at earthlink.net     FAX:    425-313-1042