Sarkela wrote:
> 
> Since this branch is favoring simplicity over features, it is
> smaller and simpler. Mainline Squeak can benefit immediately
> from the unit tests we have written. Over time SqC can incorporate
> our base changes, or come up with better solutions that address
> the same issues. In any event, the long term goal is to incorporate
> more and more of the base image functionality in the Squeak world
> tour environment as loadable source code. It will always lag
> the base in feature set.

Sounds like an excellent plan.  (In some ways a complete merge sometime in the future would be nice, but it might be a bit unrealistic, too.)

> It may even support other experimental
> interface projects. Our points of view are the principle
> limiting factors. The goals of the Squeak world tour and SqC
> are different, but they are more complementary than conflicting.
> There is an interesting dynamic tension between production coding
> values and the values of experimental development. Both are crucial.
> I expect the development of each to be a co-evolution.
> 
> Why should you expect more openness in the future? Because,
> the Squeak world tour has reached the stage of an initial release.

Hooray! :)

> Every effort is being made to avoid licensing issues and I have
> erred on the side of caution. This is in the final round of
> validation.

Good to hear.  I'm hoping that it will be made public soon... (say, in the next month or so?)  I would almost prefer to see a not-quite-rock-solid version be initially released, than to have to wait until after ESUG to see something.  You could always call the initial public release a "beta", which folks could play around with and figure out how to use, and then release a "1.0" version a few months later for people to start doing real work (and doing projects similar to the ones mentioned in your other email).

Of course, if there are still licensing issues to be worked out, that's another matter, and I can understand a delay for that reason.

(But it was looking good at Smalltalk Solutions, and I'd like to see it released soon!)

- Doug Way
  dway at riskmetrics.com


> Hopefully it will spawn a flurry of forks when it is released.
> We hope to facilitate moving functionality between forks in
> the code base.
> 
> [|] John Sarkela
> 
> Man ist vas er isst. ;-}> See you in Essen.
> 
> > From: Michael Rueger <m.rueger at acm.org>
> > Reply-To: squeak at cs.uiuc.edu
> > Date: Wed, 18 Apr 2001 08:55:01 -0700
> > To: Squeak <squeak at cs.uiuc.edu>
> > Subject: Re: Stable Squeak?
> > Resent-From: squeak at cs.uiuc.edu
> > Resent-Date: 18 Apr 2001 15:55:57 -0000
> >
> >
> >
> > Andreas Kuckartz wrote:
> >
> >> I still do not see a need for a project fork which is not even prepared
> >> openly.
> > I agree with you that the work could have been more publicized, but...
> > The whole idea of Squeak is to encourage everyone to do whatever they
> > want. Interestingly both Alan Kay and Dave Thomas actually encouraged
> > people to do this in their keynotes at SmalltalkSolutions.
> > Standardization is stagnation, and we already have enough systems that
> > are standardized, haven't we? ;-)
> >
> >> Which of these features are incompatible with the aims of SqC ?
> > Actually none. And stable Squeak is not intended to be incompatible, the
> > idea (John correct me if I put this wrong) is to take a breath, take a
> > very close look at the system and work out some issues like modularity,
> > refactoring, cleanup of historically "grown" code that later will
> > benefit the "mainstream" Squeak tremendously.
> >
> >> Why should I expect more openness in the future?
> > Be patient just a little while longer.
> > And, the world tour is coming almost to your home town in August (ESUG
> > in Essen), for LA that would be considered walking distance (except
> > nobody would walk here ;-) ).
> >
> > Michael
> >
> >
> > --
> > "To improve is to change, to be perfect is to change often."
> > Winston Churchill
> > +------------------------------------------------------------+
> > | Michael Rueger    m.rueger at acm.org      ++1 (310) 937 7196 |
> > +------------------------------------------------------------+
> >