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