Hi!

Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
> Hi goran
> 
> my remark is simply that we ***need*** packages. We should not rely on 
> *** in category to deal with class extension.

Of course - I agree. Note: We are not in disagreement here!
 
> > Hmmm, I am not so sure about the "missed opportunity" part.
> >
> > I recall that Joseph was unsure about licensing (he hadn't dropped the
> > idea of doing something commercial with it) and IMHO he wasn't very 
> > keen
> > on working "in the community" - he seems more of a lone wolf and there
> > is nothing wrong with that of course, especially since he is a very
> > competent wolf.
> 
> But we do not care about joseph this is not the point. The point is the 
> design
> of packages and bundles as true entity.

Again - I agree. My little explanation was *only* referring to the
"missed opportunity" part.
Because I don't view it as a missed opportunity. In other words - I am
not at all sure that it would have been successful if we had gone with
trying to adopt Ginzu instead.

And that was *all* I was talking about. And it was and still is a
*personal reflection*. Nothing else.

> > BUT... similarly to what happened with 3.3a that kind of setup may
> > quickly turn into an uncomfortable situation. These things and
> > architectures really *need* to be broadly anchored in the community.
> 
> But people know are much more packages aware. Education was good.
> Soon they will start to complain that SqueakMap is not good enough.....
> Am I wrong?

No you are not wrong, and again - we are not in disagreement. :-)
Yes, people are more packages aware.
Yes, education is good.
Yes, people are complaining about SqueakMap (but they have been doing
that from day one... No, just kidding).
Yes, we should look at Ginzu and everything else that we can/are allowed
to look at to learn more. Yes, we need source management tools.

...and probably a bunch of more "Yes"es.

But I still don't view the "non adoption" of Ginzu as a "missed
opportunity". ;-)

> >  And
> > if there are cruical areas that one or two people more or less controls
> > due to their unique insight and competence - it is very important that
> > those individuals really are interested in working *in* the community.
> > Like Anthony for example - I am truly impressed with his work and I can
> > promise you that such a dedication will *not* go wasted - we definitely
> > are going to lift his work into Squeak as soon as we can manage.
> 
> Good for him

Yes, but do you agree with the point I am trying to make?
 
> > And btw - Ginzu/Monticello are source management tools. What SqC wanted
> > in 3.3a was a namespace/module mechanism - not a source management 
> > tool.
> 
> But what we need now is a source management tool. Look how dependency 
> between
> changeset are missing, look how terrible is to define extension.
> 
> I work daily with store and this is good! We open our store repository 
> to some
> squeakers and once said we would love to have that for Squeak.
> 
> So that's why if Avi with monticello is going in that direction we will 
> try to help
> because this is needed. Even if classBoxes would be competing concepts 
> and we would not have scientific interest there.

Again, I agree that we need source management tools. As a matter of fact
I was one of those that spurred Avi/Colin/Ned on at OOPSLA to start
implementing Monticello.

I still though would like to keep package mechanisms separate from
source managament tools (in some critical ways). We should be able to
have multiple source management solutions but we still want to handle
dependencies between packages in ONE way. Hopefully through SM1.1+.

Otherwise everything can turn into chaos.

This doesn't mean that source management tools can't have their own
internal dependency mechanisms though.

> Stef

regards, Göran