[V3dot10] needed tool
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
I must be wrong, but I'd like to understand how such situation is dealt with
> 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?
> -Ralph Johnson
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
More information about the V3dot10