[From the soapbox:] Update stream are essential!!!
Andreas Raab
andreas.raab at gmx.de
Wed Feb 7 00:49:35 UTC 2007
Jerome Peace wrote:
> My point is that 9 out of ten of the "smartest and
> most efficient Squeakers". choose to develop and
> express their vision, focus, with execution using
> update streams.
Not in my experience. Except for the OLPC team I don't know any other
serious development effort that is based on change sets (if you disagree
name a few). And mostly I would claim for OLPC this is due to historical
reasons, e.g., we've always used updates for eToys and there isn't any
compelling reason to change that, in particular considering that the
people involved have exhaustive experience with managing update streams.
> Process has a direct relationship to results.
That is certainly true.
> Anyone can update and save a current OPLC system in a
> handful of minutes.
Yes, that is also true and one of the powerful things about incremental
updates. On the other hand, try to port changes from the OLPC image to
Squeak 3.9 and see how that goes. You'll go wildly fishing through a
large number of changes desperately trying to figure out what got
changed where and which effect it might have on other ends of the system
and how (and if) it depends on changes done three months ago. Been
there, done that. Monticello makes that kind of stuff really easy - if
we need fixes in Qwaq's internal version of some package we simply do
them and at some point we merely merge them back into the public version
and we're done. We can always look what has changed where, when and how.
In any case, those are different trade-offs for different styles of work
and different goals. If you want to make progress quickly, updates and
change sets might be for you. If you want to be able to reflect about
the changes in an organized manner and move code between various images
and versions, Monticello is pretty much the only choice.
Another way to look at the above is where you put the time - updates are
mostly "back-end loaded" as they will require very significant work if
you ever need to do anything with the code after it is out, whereas
Monticello is more "front-end loaded", requiring to put more thought in
before you do things. That means Monticello is intrinsically slower to
develop initially but also more stable in the long-term. Both of these
observations match exactly my experience with both development styles.
But by the end of the day I'd still insist that the main difference is
not in those tools but rather in the people working with them.
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|