Hi All,

If we fix Monticello Configurations
(http://bugs.impara.de/view.php?id=5217), it can become an update stream.
It's quick and easy to do.  As for speed, I've found it to be very
responsive as long as SqueakSource is running!  I work with the latest code
from many different projects, which is not always fun since people do change
things I depend on!  But I find and fix a lot of bugs that way.

Here is what I do.

| config |

config := (
(MCHttpRepository
	location: 'http://www.squeaksource.com/ARepository'
	user: 'aUserName'
	password: 'aPassword')
versionReaderForFileNamed: 'aConfigFileName.mcm') loadConfiguration
configuration.
config updateFromRepositories upgradeByLoading

(upgradeByLoading prevents the system from overwriting things that you
changed in your image, this can be changed by load which will ask you or
upgradeByMerging which will merge changes)

If we used something like this then any changes saved to a Monticello
repository included in the, let's call it 'updateSteam.mcm', Monticello
configuration file will automatically get loaded.  This works for changes in
any repository not just the one that stores the mcm file, since
configuration files stores and searches though multiple repositories.  

We could have it ask if you want to load changes durring start up like
updateStreams do now.  It could easily tell you what packages have been
updated and even show you the comments of the update.  (In fact those
changes are shown on the transcript now during updateFromRepositories.)  You
could even have different config files to update different parts of the
system.  You could pick from which config files you are interested in and
have the system update the ini file with that info.  MorphicUpdate.mcm,
Network.mcm, EToyLoadForKernalImage.mcm ...

Just some thoughts.

Yours,

Ron Teitelbaum

> From: Jerome Peace
> Sent: Thursday, February 08, 2007 3:35 PM
> 
>  [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/
>