Colin I want to thank you for all the cool stuff you are giving us.
I still had no time to look at MC2 (I'm in painting and boxes for my  
move + all the other mess)
but I would like to use it.

Stef

> Hi Daniel, Ralph,
>
> I think Daniel is absolutely right in his focus on cyclic  
> dependencies. The difficulty in decomposing Squeak is because of  
> the interaction of three factors, IMO:
>
> 1) It's awfully difficult to collaborate, especially in ad-hoc,  
> distributed communities, without good version control
>
> 2) Monticello doesn't deal well at all with large, monolithic  
> bodies of code or cyclic dependencies
>
> 3) Squeak is large, monolithic body of code rife with ill-defined  
> and often cyclic dependencies
>
> As a point of comparison, look at the Seaside sub-community.  
> Seaside2 has been under version control for its entire life, and  
> the Seaside community has generally adopted Monticello for their  
> Seaside projects. The issues we've struggled with and repeatedly  
> debated in Squeak have been resolved without much discussion or  
> effort in Seaside. The code base is modular and generally-well  
> factored. Most packages are reasonably well maintained, but even  
> packages with absentee maintainers tend to get fixes and "hacked"  
> versions are available in one place or another. This works because  
> the Seaside community just treats the underlying platform as a  
> mostly opaque substrate and builds everything on top of it.
>
> More comments inline:
>
> On May 20, 2006, at 6:42 AM, Daniel Vainsencher wrote:
>
>> Package system:
>> --------------------------
>> I believe that the management of the code of Squeak in tool  
>> supported packages is a critical component of any solution - this  
>> is the only way to keep the boundaries up to date. So the  
>> existance of MC exists makes this task somewhat feasible, but  
>> there have been various problems with its use to manage the whole  
>> image.
>>
>> - Performance (loading updates to the image using MC is much  
>> slower than loading changesets).
>
> There are several aspects to this, but the primary one is that MC  
> doesn't version code so much as packages. Because of the dependency  
> issues in Squeak, packages are either really big, or a "small"  
> change touches a lot of them. Either way, it means moving a lot  
> more data and doing more work to update image than what is required  
> for a change set. In practice, that makes it too slow everyday  
> workflow.
>
> MC2 actually versions code, so it has a lot more flexibility. It  
> would be possible, for example, to create an update stream of  
> "versioned changesets" that wouldn't carry too much overhead  
> compared to the classical update stream.
>
>> - System changes (like introducing Traits) require going through  
>> various intermediate stages, but MC itself only model merging the  
>> code in order to reach the final stage to be loaded.
>
> Yes. It's surprising how little this has affected at the higher  
> levels of the system. (For example, MC can usually update itself  
> without problems.) To manage all of Squeak, though, I don't think  
> we'll be able to escape having some kind of update stream based on  
> filing in arbitrary code.
>
> MC2 can help with this part as well. It can do atomic updates to  
> the image, so the cases that require carefully orchestrated  
> migrations should be very rare. I'm imagining only issuing updates  
> every year or two, and having stuff stay pretty compatible in  
> between updates.
>
>> - Workflow:
>> -- Support for cherry picking is very basic in current MC (which  
>> MC2 should improve).
>
> Yes. Cherry picking is surprisingly important, and MC2 should do  
> merges in general better than MC1 does.
>
>> -- MC is quite workflow agnostic, but maintaining Squeak does  
>> require some workflow (people write fixes, other people merge  
>> them), and maintaining it as a set of packages requires even more  
>> of it (coordination of entry of package changes into the official  
>> release). Right now we use a combination of SqueakSource, Mantis,  
>> and email, glued together by (what seems to me like) lots of  
>> overhead.
>
> Breaking the dependencies is hard work. Monticello is making it  
> even harder, because it's really meant to work on systems that are  
> already decomposed. It expects to work on packages with stable  
> boundaries and acyclical dependencies, and ties versioning very  
> tightly to that model. It's too early to say yet, but since MC2  
> does versioning without requiring packages, I'm hopeful that it can  
> help with the modularization workflow more effectively than MC1.
>
> Colin
>