[V3dot10] needed tool

Milan Zimmermann milan.zimmermann at sympatico.ca
Tue Jan 23 06:38:00 UTC 2007

On 2007 January 22 10:42, Ralph Johnson wrote:
> On 1/21/07, Milan Zimmermann <milan.zimmermann at sympatico.ca> wrote:
> > Experiences Squeakers, let me understand this problem some more. I
> > understand how a changeset can contain code that "belongs" to several
> > Monticello Packages. What I do not know is how much code is currently
> > maintained in Monticello vs Changesets.
> The 3.9 group put ALL of the code in the basic image in Monticello.

Ah yes thanks! .. I just browsed Monticello in 3.9 with a new set of eyes. I 
did not realize all this Monticello-type categorization was done in 3.9 (I 
did not realize it before because the list of packages was so much shorter 
than list of class categories). This must have been a huge amount of work, 
renaming the method categories to Monticello naming conventions.

> The MC packages that result are not what I think of as a package, a
> coherent component that can be used or not used as needed.  

I am pondering all along, how to think of a Monticello Package, whether it 
should be thought of as (vaguely) an "application component" or "deployment 
package". I feel it is the later (deployment package) and perhaps another 
tool is needed or exists to define what classes form a component. I guess 
class category is historically closer to a component (but I am simply without 
sufficient experience with Smalltalk to resolve that for myself).

> They ran 
> into a number of problems using MC.  Nevertheless, they succeeded, and
> their opinion is that we should go forward and improve how MC is used
> rather than go back to change sets.

Well, for what's worth, I like Monticello very much and I feel Changesets are 
too low level (but are more "powerful")... I feel with Monticello 
one "potential problem" comes in a situation like this: There is a method 
MyClass>#myMethod. It belongs, according to Monticello naming, to MC Package 
MyPackage. The someone writes a new application, the new application belongs 
to Monticello Package NewPackage, and New Package decides to modify 
MyClass>#myMethod, and add a line into it. (To me, this is scary, but it 
seems hapenning.) . How does Monticello deal with this? It can "steal" 
MyClass>#myMethod and make it part of NewPackage (by changing it's method 
category), but then that breaks MyPackage. If NewPackage does not "steal" the 
method, how can it "claim" that one line change for itself? Perhaps 
such "stealing" was one of the problems Stef and Marcus ran into, but I do 
not remember that from reading the post mortem 
http://www.iam.unibe.ch/~scg/Archive/Papers/Denk07aErcimEvolutionSqueak.pdf ..  
I must be wrong, but I'd like to understand how such situation is dealt with 
in Monticello.

> So, ALL code in the image is in Monticello from the point of view of
> the release team.  The average Squeak programmer does not have to pay
> any attention to this and can continue to file out changesets.  But
> the release team needs to convert between the two.

Yes. And due to the fact all Squeak is in the 3.9 image is in Monticello, as 
you pointed out, it should be possible to look into the changeset (assuming 
it is exported from 3.9!!) , and "derive" from the contained  method names, 
method categories and class categories to which  Monticello Package(s) it 
belongs. Does this make sense on the high level?

Thanks Milan

> -Ralph Johnson
> _______________________________________________
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/v3dot10

More information about the V3dot10 mailing list