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