Hi all!

Anthony Anton <agantoniii at earthlink.net> wrote:
> My prior comments should have included the information that I have 
> been using Package Loader for all package/update installations and 

The Package Loader uses the "appropriate tool" depending on the package
you install.

In other words - SM itself has no real part in the problems here. It has
purely to do with packages "stepping on each other" or as Avi explained
- new releases as changesets, which simply is not a reliable format when
upgrades are intended. Given the availability of Monticello there is no
point anymore in using .cs format for packages.

[SNIP]
> >   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).

It is being used for the packages that use that format. SM sees to that.

> 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.

Well, the technical part has "been handled" IMHO - meaning that if
people migrate over to using Monticello - which will happen more and
more, especially since the standard packages most surely will use that
format - then upgrades will be technically "sound".

So yes, do try out Monticello - you will not regret it. It is simply
great.

The problem with packages stepping on each other is still left to handle
of course.

> >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."

Not sure what that means. You are referring to the "New objects" view on
the SM website?
Yes, that only lists, well, "new objects". :) Not changes to old ones.

Sidenote: Problems with Whisker and BrowseUnit are most surely related
to the fact that they both deal with the same areas of the image. Just a
wild guess of course.

[SNIP]
> 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.

Well, IMHO most of the problems for us to solve here are related to
inter-package management.
Monticello has more or less nailed down the issue of source code
management of a package.

This in turns points a finger towards SM. What I mean is the problems
arising when combining different releases of various packages. Are they
compatible? Do the conflict with each other?

These issues are quite high on my agenda for SM, though I have been in a
"slump" the last week or so - much other things to handle in my life.

regards, Göran