updates vs. images
Ron Teitelbaum
Ron at USMedRec.com
Thu Oct 13 01:11:13 UTC 2005
Avi,
I probably should stay out of this, esp since I'm not even using the update
stream. I'm using 3.8. The reason for that is I'm developing code that is
not intended for Squeak and I need stability for development. If I were
developing code for squeak I would want to stay as current as possible to
allow me to integrate my changes into the most current environment. I'm my
experience there are tremendous benefits to continuous integration when
large volumes of code are changing at the same time. The benefits are
mostly at reconcile time, but also it helps to identify bad code more
quickly or it allows developers to take advantage of changes as they happen
and it prevents users from fixing the same bug over and over (like Andreas'
chess game, which I submitted a change to without talking to him). With
continuous integration it is much less likely that another change will break
my code. I know that there are always integration problems but I really
think developing from the most current editions of methods really helps get
developers on the same page.
I would also argue that the alpha image should be loosely controlled.
Things should be allowed to break, breaks should be fixed quickly, and
developers should be responsible for the code they submit (responsible to
test it before releasing it, and responsible for fixing anything that it
breaks, or the code should be backed out). It becomes obvious which changes
are bad as long as others are using the code that is being changed (which
argues for qa) and pressure from other developers to fix it help to increase
developer unit testing before release.
For what it's worth,
Ron
-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of Avi
Bryant
Sent: Wednesday, October 12, 2005 6:11 PM
To: The general-purpose Squeak developers list
Subject: updates vs. images
To throw some new (and maybe novel) fuel on the recent fires around
harvesting and the update stream: why do we need an update stream at
all?
Other Smalltalks - VisualWorks, Dolphin, etc - simply release new
images when there are new versions, and everyone is expected to
reinstall their code into that. Bootstrapping problems have to be
solved once, by the vendor, and everyone uses the same resulting
image. As long as it's simple enough to load your own packages in -
and Monticello at least handles *that* pretty well - this should be
pretty easy for the user. In practice, in fact, this is exactly what
I do already - I just download the latest image Marcus puts out and
go from there. I suspect lots of others do the same thing.
Now, I realize that the update stream is more important for some
segments of the Squeak community than for others. In Squeakland,
most of the interesting content cannot be captured by a Monticello
package, and is at least somewhat harder to load into a new image -
and so the desire to update the existing image is stronger than it
would be for those of us doing "code-only" work. I imagine similar
concerns apply in the Tweak world, and I'm sure they do for Croquet.
But then, don't those groups maintain update streams separate from
what I guess we could call the "Squeak Foundation stream" already? I
doubt things would change much there no matter what SqF did with its
stream, including getting rid of it entirely.
The reason that I propose this is that the sense I get from Marcus
and Stef and others involved in the harvesting process is that the
main difficulty is not one of evaluating and integrating changes, but
of preparing those changes for the stream. Generally, it's easy for
someone to produce a single image that's properly integrated, and
even to record that state in a set of package versions suitable for
people to submit changes against for later integration. What's slow
and unreliable is setting things up so that some other arbitrary
image can go through the "same" set of changes. Frankly, although
Monticello is a pretty decent tool for development work - it handles
submitting and integrating changes fairly well - it's showing itself
to be a really bad tool for deploying changes. On the other hand,
images are a *great* deployment mechanism.
Thoughts?
Avi
More information about the Squeak-dev
mailing list
|