Hrm, interesting conversation.  Change sets and Monticello have different 
ways of recording changes right? How clean is the change system from each?  
I am just wondering if a concept like darc's "theory of patches" could 
replace the current systems (at some point far far into the future :) and 
make them all work better together.


>From: Jerome Peace <peace_the_dreamer at yahoo.com>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: squeak-dev at lists.squeakfoundation.org
>Subject: [From the soapbox:] Update stream are essential!!!
>Date: Thu, 8 Feb 2007 12:35:14 -0800 (PST)
>
>  [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).
>
>The context in which I am talking is in maintaining an
>image.
>
>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.
>
>My position is not to go back to changesets and
>abandon MC. My position is that the two need to
>interoperate.
>Right now MC kills the usefulness of changesets
>because of its use of catagories to determine
>packages. That is the current unfortunate limitation.
>
>
>
> >  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.
>
>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?
>
>There is some difference in our experiences.
> >
> >  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.
>
>Yes. And when is it important to do each of those
>things?
>
>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.
>
>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.
>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.
>
>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")
>
>
> >
> >  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.
>
>Yes, this is like the cathedral and the bazaar
>comparison.  Or water and ice.
>My veiwpoint would say MC is slower to use and harder
>to change.
>
>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.
>
>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.
>
> >  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.
>
>"You get good results from good choices.
>You learn to make go choices from experience.
>You get experience from  making bad choices."  --
>unknown.
>
>
> >  Cheers,
> >     - Andreas
>
>***
> >  [From the soapbox:] Update stream are essential!!!
> >
> >  Andreas Raab andreas.raab at gmx.de
> >  Wed Feb 7 10:23:22 UTC 2007
> >
> >  Jerome Peace wrote:
> >  > This is a life destroying decision for the squeak
> >  > community.
> >  >
> >  > Look at how fast the OPLC team develops
>improvements
> >  > and look at the level of feedback they get.
> >  >
> >  > Now compare that with the glacial pace of the
>squeak
> >  > image.
> >
> >  (Just because I only noticed it and it's so fitting
>in
> >  this discussion)
> >  Even if you do consider The Image to be the sine
>qua
> >  non of Squeak, you
> >  might want to have a look at:
> >
> >  http://weeklysqueak.wordpress.com/2007/02/04/
> >  recent-squeak-packages-releases-2/
> >
> >  which may give you a different view of the
>"glacial"
> >  pace at which the
> >  community as a whole moves. There is a whole lot of
> >  stuff going on if
> >  you are willing to look beyond the image in front
>of
> >  you.
> >
> >  Cheers,
> >     - Andreas
>***
>
>Cool.  Good point.
>
>Thank you for the engaging conversation so far.
>
>Yours in curiosity and service, -- Jerome Peace
> >
> >
>
>
>
>____________________________________________________________________________________
>Looking for earth-friendly autos?
>Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
>http://autos.yahoo.com/green_center/
>

_________________________________________________________________
Laugh, share and connect with Windows Live Messenger 
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline