Hi Brad,

It's not just sinking in that is an issue.  I'm also considering the
practical aspects.  Also I'm not exactly sure how this all fits with
Andreas' suggestion of managing packages outside the context of an official
image.

I can't help seeing the down side to all of this, and I wonder what the
impact will be for those starting out with Squeak.

The issue with too much freedom is that anyone is allowed to break things.
We have enough trouble as it is with class clutter.  Even I tried
(unsuccessfully) to add to Collection.  

So let's say we go with this path and anyone can start a stream.  How does a
user decide which stream to use?  If we have two very good streams (like
Sophie and Croquet) which are changing classes in an incompatible way then
someone's changes are still lost.

I like the idea of making it easier for people to contribute.  Our
discussions earlier about commenting code is really hampered by how
difficult it is to add comments and have those comments included somewhere.


I like the idea of passing the streams or having stream managers, or
something like that, so that there is one official stream per package.  But
of course this really just brings us back to squeak map and away from a
change stream.  I like Andreas' suggestion that we try to support standard
packages for multiple images.

So I guess I was no help but still we need to consider if we have a Ron's
collection stream and nobody hears it does it still make a sound?  

How can we move from what we have now to a place where it is easy for
someone to push quality changes or new code into production?  Can we really
support a free for all collection of change streams, or do we need to stick
with standard packages?  If we agree we need standard packages what do we
gain from a change stream?

Ron Teitelbaum

> -----Original Message-----
> From: Brad Fuller
> 
> Göran,
> 
> I'm surprised with the lack of response to your post. Maybe people are
> letting
> it sink in. I think it's a great idea. FMPOV, the tool would be a clean
> way
> for the developer and user to accept bug fixes into his image. Why not
> make
> bug fixes easily available to everyone? It's also a nice way to put a
> method
> around all the fixes just lying there in various forms and places. And, it
> seems a nice way to update released images on ftp.squeak.org with proper
> fixes - at least the fairly new ones.
> 
> The concept and high-level usage is a no-brainer. The tough part is
> getting it
> done.  Since a lot of the work is creating the tool description, and you
> have
> a great handle on that already, I wouldn't be surprised if you've already
> started coding.
> 
> brad