One last try (was: RE: Convincing a harvester (was on SqF list))

Andreas Raab andreas.raab at gmx.de
Wed May 7 18:47:07 UTC 2003


Daniel,

> 1. Guides can veto the inclusion of changes into the image.

Correct (though I would phrase it differently).

> 2. The image(s) available at any given moment IS the 
> expressed strategy of Squeak. Stuff available at SM
> is not relevant, because it is not as immidiately accessible.
> You're not saying this explicitly, but seem to
> be assuming it. Right?

Yes.

> 3. Guides do not de-facto actively pursue a strategy of 
> Squeak as media platform (because they don't recognize and
> include in the current image stuff that would advance it).

No. They _do_ pursue a strategy (which was the point of my last post).

> 4. Or any other topical strategy, because the main thing they 
> care about is just <the stuff we do persue>.

Yes. (btw, I am not having a problem with this)

> 5. 1+2+3+4 mean that nobody else can pursue a strategy, and Squeak is
> not being a platform for people, as we say it should be, and 
> that sucks.

Almost. (there is something in the above which bothers me but I can't say
exactly what)

> We do intend to have multiple images, starting soon - with 3.6's
> release. This will include the "full" image, which I think everyone
> agrees should be a "media platform", among things, since cool demos
> pretty much require media stuff. This image would be "base" + a set of
> packages preloaded. To avoid becoming a fork, this image 
> should try hard to include packages that are mostly modules.
> It can apply patch packages, if it avoids patches to "base" stuff,
> so that development done on this image is shareable with "base".
> It would obviously need to be led by someone media oriented. 
> 
> Does this solve the part that bugs you specifically? if not, how?

If I would think that having multiple images that way would solve the
problems I wouldn't even have started the discussion. In short, I don't
trust this approach very far though it is hard for me to explain exactly
why. Perhaps another analogy with the Linux world and its distros is
appropriate. What you see is effectively a split of the community around the
different distros and in the Squeak case this might be even more complex
since it is likely that significant work will be done in the various
versions. 

Consider a situation where we use a method in distro X which is not in
distro Y (or implement a selector which is not in distro Y but defined by
someone else in distro X). What's going to happen? Stuff breaks. Meaning
that we'll soon have packages which work only for distro X, Y, or Z. Meaning
that the overhead which is required to make "all around versions" for
something triples (this is similar to changing versions but now we suddenly
have a couple of versions which we need to test against). And I don't think
the community can survive this split (it's too small for it) and people will
see Squeak as a thing "where things just don't work" as a package loaded
into one distro works perfectly fine and breaks in another one. And then,
people will (merely to avoid this image) start thinking very hard about
giving their distro a different name, setting up their own servers for the
packages and you got a couple of forks ahead of you. I'll leave it up to
your judgement if the Squeak community can afford this.

Cheers,
  - Andreas



More information about the Squeak-dev mailing list