[From the soapbox:] Update stream are essential!!!
J J
azreal1977 at hotmail.com
Thu Feb 8 21:31:13 UTC 2007
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
More information about the Squeak-dev
mailing list
|