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