[From the soapbox:] Update stream are essential!!!

>  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

>  [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

> 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/
>

>From: Jerome Peace <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: [hidden email]
>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/
>

> 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