Jerome Peace wrote:
> The context in which I am talking is in maintaining an
> image.

Well, that's a difficult statement. What defines "maintaining an image"? 
In particular comparing the activities of OLPC, Seaside, Sophie, 
Croquet, and/or Squeak.org? Which of those do maintain images and which 
ones don't? And why?

> A development project with clear boundries may work
> very well for a time if it starts in MC.
> But once it starts there its locked in.  It can't go
> back and forth between change set development and MC
> development. That is an unfortunate limitation. The
> more developed a package gets the more it the code
> will want to shift between packages or will want to be
> placed in a new package of its own. MC does not
> facilitate interpackage development changesets do.

Indeed. Personally, I consider this an advantage although it can be a 
little bothersome at times. But keeping changes local to a package, 
encapsulating them inside a package is generally a good thing.

> My position is not to go back to changesets and
> abandon MC. My position is that the two need to
> interoperate.

And I would love nothing better!

> Right now MC kills the usefulness of changesets
> because of its use of catagories to determine
> packages. That is the current unfortunate limitation.

Well, but that goes both ways. Changesets kill the usefulness of 
Monticello since they have no discipline, no way of specifying which 
packages they affect. They carry no versions, no history either, they 
cannot be diffed or merged.

>>  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.
> 
> Okay, thats cool. In the context of Qwaq MC works.  
> How big is Qwaq? How old is it? How long does it take
> to load and save?

Qwaq is the name of our company and it doesn't load and save very well ;-)

> There is some difference in our experiences.

Yes, very likely so. I have spent much of the last years in environments 
where I had to constantly maintain various versions of images (Tweak, 
Croquet, Tweak in the context of Tinlizzie, Tweak in the context of 
Impara and its products, later Croquet in the context of Qwaq etc.) 
Doing this would have been plain impossible without the help of 
Monticello. Comparing this with my prior (SqC) experience shows the 
differences quite clearly - during the SqC days we were only concerned 
with a single image and updates are by far superior if you don't have to 
maintain multiple images and versions.

I do think that Squeak.org should support the multiple-image style more 
than the single-image style though - if only because all "serious" 
developers will likely have to support various image versions, and in 
this case using MC simply has dramatic advantages. It also helps 
breaking out parts and understanding where the boundaries are (but this 
is a secondary aspect in this discussion).

>>  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.
> 
> Yes. And when is it important to do each of those
> things?

Depends on what you do. For me, it's my primary mode of working. The 
first thing in the morning is doing a diff of the latest check-in 
against my local modifications, merging so that things don't go too far 
astray. I used to do this differently by filing out CS'es in the 
evening, then updating in the morning and then filing in my changes 
again, but fortunately, I don't need that any longer.

> In the context of maintaining the image and repairing
> problems I want to be able to make progress quickly
> and later at leisure determine how to separate things
> into packages. Good repairs desire to be allowed to
> happen across packages.

Actually, if you use it correctly, Monticello does allow all of that. 
What it can't deal with very well is doing these modifications as 
surgery on a running system. That is its major shortcoming.

> In the context of developing an alpha image I want
> frequent and wide distribution of the image to
> interested test pilots so that they can unmask bugs.
> The bugs can be patched. And the bugs uncovered by the
> fixes found.

Other than speed, I see little contradiction between the workflow you 
describe and Monticello. And if the package boundaries were more 
well-defined this would likely not be a big issue either.

> As I've tracked thru squeak I've had a better
> opportunity to find bugs because of they were hiding
> behind bugs I've patched. Also sometimes a hasty patch
> of mine has slipped into the stream and caused its own
> bug.  I usally find it and fix it quickly. But if it
> can't get in to the update stream quickly then others
> waste a lot of time refinding the same bug instead of
> finding new ones.

The issue of round-trip time seems unrelated to Monticello to me - even 
if uploads are slow they certainly don't take days to complete. Those 
issues have gating items elsewhere.

> In the context of maintaining an image MC is not the
> completely right tool. It causes things to happen out
> of sequence and puts pressures on programmers to
> include messages in the wrong packages to avoid the
> work of getting multiple permission. (As Tim says
> "Don't ask me how I know this")

On this particular issue I very strongly disagree. You don't have to get 
permission - you can make forks of packages and it is *utterly* trivial 
to merge these changes back. Monticello is *made for this* it excels at 
dealing with multiple forks, there is no reason *ever* to include 
messages in wrong packages (or even worse use overrides).

> Changesets are essential because they provide the
> mechanism for repair by rapid learning.
> Like McCready's gossamar condor being built out of
> balsa wood, piano wire, and duct tape. In the context
> of getting an image to work you need to be able to
> learn your lessons quickly, repair them and learn the
> lessons that are now newly exposed by the repairs. For
> that you need changesets.

You seem to be ultimately coming down to speed here (and also in your 
previous argumentation). I don't think any of these arguments would be 
made that way if the loading speed of an MC package would be comparable 
to change sets. Have you ever tried using .MCDs (server-side diffs 
between packages) that Bert did for precisely the reason of accelerating 
downloads?

> When things are working (lots of little repairs)
> taking stock and packaging what is willing to be
> packaged is a good way to preserve the gains.  So my
> point is that choosing to make MC packages first and
> to build the image solely from those is out of
> sequence.

Yes, there is something to be said for this - but only if your interest 
is in the artifact more than it is in the progress towards the artifact 
(which is admittedly true for most people who don't want/need to track 
ongoing development).

>>  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.
> Yes, and good people will always seek the most
> appropriate tools and sequences for the job at hand.
> If a person has the spirit to learn from there
> mistakes. They will improve most rapidly in their
> quality and experience if they are allow to get thru
> thier mistakes quickly and often.

I'm not sure if this is meant to be read that way but I would not call 
the use of Monticello a "mistake to be learned from", since to me it is 
not a mistake but rather a huge step forward towards distributed 
development.

Cheers,
   - Andreas