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

Jerome Peace peace_the_dreamer at yahoo.com
Thu Feb 8 20:35:14 UTC 2007


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



More information about the Squeak-dev mailing list