Some thoughts 2/3: Preparing 3.9
stéphane ducasse
ducasse at iam.unibe.ch
Tue Sep 14 14:33:36 UTC 2004
>>>
Hi avi
I'm biased :), but I would like to get rid of categories and have
transparent packages instead so I would favor
the solution one, even if this may be a problem for people willing to
have tiny images. I think that with MC we could
have a real "pseudo-class" functionality and perform much better
analysis of code not installed in the model.
stef
>>> We actually discussed this a bit earlier (although no one summarized
>>> the reasons as well as you did here) and generally agreed that
>>> Monticello should go in 3.8. It's actually in the plan for 3.8:
>>>
>>> http://minnow.cc.gatech.edu/squeak/3832
>>
>> I assume you're speaking about the full image, right? We agreed
>> earlier on that no packaging system should go into the base image,
>> but only the infrastructure necessary to build one, in particular
>> PackageInfo. I agree it should make it into the full image which has
>> all sorts of developer tools.
>
> We've agreed various things at various times, mostly because
> "agreeing" in this case usually means that a few people say "yes,
> sounds good" and those who object don't notice the thread or choose
> not to argue.
>
> From my point of view, the crucial issue is not what goes into the
> image so much as how we manage the update stream. People can always
> install Monticello from SqueakMap if they want to, and actually SM now
> does a pretty good job of installing it automatically when it's
> needed. But a lot of our process revolves around the update stream,
> and given that more and more core packages are being managed by
> Monticello (Markus is using it for his Compiler work and for SUnit,
> for example), there needs to be *some* kind of integration between
> them.
>
> I can think of two ways this can happen: one would be to allow .mcz or
> .mcd files to be put into the update stream directly, and handle them
> by using Monticello's automatic merging to update the image but
> preserve any local changes. This would make the user aware of any
> conflicts, and would correctly preserve the ancestry of any changes
> they made correctly, so that if the user then publishes their changes
> they can be correctly merged into other people's images as well.
> However, it would obviously require that Monticello be included at a
> fairly basic level, because the update stream wouldn't work without
> it.
>
> The second option would be for me to set up some mechanism where you
> can "commit" MC versions to the update stream, where a diff is
> automatically done against the last version of the same package that
> went in, a changeset automatically produced, and this is what actually
> goes out to people's images. Although this doesn't require MC to be
> in the base image, it means that if people *do* have MC loaded, then
> their images are going to get somewhat screwed up, since they're
> making changes to packages managed by MC without properly adjusting
> the MC ancestry metadata.
>
> I would prefer the first, but if there's opposition to that, then
> let's decide soon that we're not going to do it, so that at least I
> can implement the second and make it available.
>
> Avi
>
>
More information about the Squeak-dev
mailing list
|