An idea, crazy or not? (Re: Very bad about Squeak in blogosfere)

Andreas Raab andreas.raab at gmx.de
Tue Aug 14 05:03:12 UTC 2007


Ron Teitelbaum wrote:
> 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.

 From my perspective Goran's proposal actually provides a solution. Part 
of the problem with the current setup is that it's plain impossible to 
go through all of the versions that were generated by the 3.10 team and 
try to figure out which ones contain fixes that apply to Croquet and 
which ones don't. MCZs are simply to heavy-weight for this process. 
Delta streams (assuming they tie in with versions) would solve the 
problem nicely.

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

There will be almost no impact. Users will find one or two subscriptions 
in their image (those for the current version they are on and maybe an 
optional one for the next alpha version) and that's it. Much like the 
update stream. The magic is upstream, by having the release stream 
aggregate fixes from various inputs and provide those in a consistent 
manner to the downstream consumers.

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

Indeed. A tool can't solve the social problems. If you have inherently 
incompatible changes then you need to make a decision which path to 
follow. However, contrary to the past you should still be able to very 
quickly follow changes on the path not taken and adapt deltas coming 
that way for whatever you need.

So that, for example Croquet can listen to the delta stream of Squeak 
3.10 and quickly filter out those changes that are relevant to its 
packages and vice versa. Both are independent but the interplay is 
simplified because it is possible to quickly screen a concise set of 
changes. Consumers of either one don't usually even get to see the other 
stream but they may subscribe directly to an upstream package stream in 
which they are interested in.

In the end what happens is that you start out with a single stream for 
your image version, moderated by whoever provides that stream. As you 
progress, you may subscribe to further upstream packages (or individual 
contributors) to get the changes you are interested in.

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

Which can be done in addition to and independent from Goran's proposal.

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

Delta streams won't replace a release team. That's for sure. What they 
should offer is the ability to very quickly pick out what changes are 
relevant to a particular fork from some set of updates. This may 
actually lead to competition and more forks but like Goran said, part of 
this proposal is to embrace change.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list