Whither Squeak?
Colin Putney
cputney at wiresong.ca
Sat May 20 18:48:53 UTC 2006
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
More information about the Squeak-dev
mailing list
|