Basic tenets of what goes in the image (was: [Squeakfoundation]Flow integration)

[goran.hultgren@bluefish.se]

Daniel Vainsencher <danielv@netvision.net.il> wrote:
> Hmm, I think it's clear we're not all on the same page here, and I think
> we better address this sooner rather than later.
> 
> This is my proposed base policy on what should go into the image
> * Has to help all Squeakers. Being cool (Connectors) doesn't cut it -
> that can live on SM. TestRunner ENHs encourage more SUnit tests, so they
> might go in.
> * It has to be stable. There is no reason now to integrate unstable
> code. Young code can live on SM until it's tested. If package
> maintainers prefer it to what's in the image, let them depend on it.
> This has two benefits -
>  - Acceptance in the community is not binary - you can have users, even
> many, before the code is in the image.
>  - The use and testing will make the code stable, at which point, we can
> put it in the image.
> * It has to be understandable. Add class comments, reduce class
> count/size, reduce functionality to the minimum that really needs to be
> in the image. Just keep it simple.
> 
> If we let things in the image that make it bloated, or unstable, or even
> stable but unmaintainable, we're eating the goose. I think if we're
> commited to making Squeak viable in the long term, we need to keep these
> things as high priorities.

Daniel, I agree with everything you say BUT on the other hand I
*strongly* disagree! ;-)

My point being that new stuff should simple NOT go into the image *at
all*! It seems to me that you are perhaps forgetting the base principle
that only fixes+really good enhs+package removals should go into the
base image! It is easy to forget though - we all tend to do that in
these discussions.

For example, TestRunner... Why is that in the image? Cut it out into a
package.

So please, stop thinking in terms of "the base image"! Flow? It should
IMHO not go into the base image. In fact IMHO Networking should rather
be *cut out* of the image into a package. Much like Tim said in another
reply.

I also agree with Michael's idea to split the low layer from the high
layer (Sockets vs Streams typically).

(Anyway, perhaps I misunderstood Daniel here - AFAIK we are all in
agreement on this, I just didn't think it sounded like that in this
particular email. ;-) )

> At the same time, to help people that contribute work to squeak to know
> where to aim, I think we must make the criteria clear, whether we agree
> they are similar to the above or not. I reviewed the Mission Statement
> now, and it doesn't say much about it, which I think is a bug.

We can always make addendums! :-)

> I'd like comments on this at least from all Guides.
> 
> Before we decide how to get there on any specific package, we need to
> make it clear where we're going.

I strongly urge everyone to keep the focus on *packages* and not the
base image. This also applies to the discussion about 3.4alpha going
into beta and the discussion about putting SM into the base image, btw.

If people still want to talk about a "base" of some kind then by all
means we should create one! How? By selecting packages that we want to
consider to be the base packages.

regards, Göran