Hi all,

What is the criteria and approval process of being in the base image? 

brad


> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of goran.krampe at bluefish.se
> Sent: Sunday, July 11, 2004 8:59 AM
> To: The general-purpose Squeak developers list
> Subject: Re: How to improve Squeak
> 
> Hi all!
> 
> Marcus Denker <denker at iam.unibe.ch> wrote:
> > Am 11.07.2004 um 15:45 schrieb David T. Lewis:
> > > On Sun, Jul 11, 2004 at 11:55:56AM +0200, stéphane ducasse wrote:
> [SNIP]
> > > Personally, I don't mind having some incomplete or 
> unfinished things 
> > > in Squeak. Many of them show good ideas and things that could be 
> > > brought to completion in the future.
> > >
> > But there's a lot of stuff that will never be completed 
> because it was 
> > "officially"
> > abandoned. e.g. the "Squeak Server Pages" are, es much as I 
> know, an 
> > experiment that was superseded by Projects.
> 
> I agree with Marcus and also, experiments are better made in 
> a separate package. Then they don't bother anyone and can 
> "rot" in peace. :)
> 
> Having loose nobody-really-knows-if-it-works-half-rotten-half-finished
> stuff in the base image is simply not good.
> 
> > So while I'm personally very much pro experiments (and I'd 
> like to see 
> > a Squeak that makes real deep experimentation even simpler), the 
> > situation we have now has realy gotten out of hand...
> > 
> > The Number one Principle of a System made for 
> Experimentation: Make it 
> > easy to throw stuff away. It's an interesting view of Modularity: A 
> > modular system not only allows for easy composition, but 
> should make 
> > decomposition easy, too.
> 
> Yes, and we shouldn't be so scared of touching these things. 
> Either we:
> 
> 1. Cut it out and put it in a package. It doesn't even have to work.
> This option is nice if it isn't too tangled up.
> 
> 2. Delete it. Remember, there are always old images and old 
> VM to pick up and look inside if someone wants to salvage it 
> in the future.
> 
> 
> > For the Kernel, we have KCP (I hope to be able to actively 
> contribute 
> > to that). For Morphic, there once was MCP, but the state of 
> Morhpic is 
> > so bad that I guess only "thow it away" will work...
> > 
> > One question is how to make sure that something like that does not 
> > happen in the future again... for the ObjectMemory, we have an 
> > automatic garbadge collector.
> 
> Well, best is if experimental stuff are in external packages. 
> Then they can be marked clearly as half finisihed 
> experimental stuff etc. And there is a maintainer, and we can 
> see when it last worked etc.
> 
> > I think a Team doing experimental work would need to model 
> a "garbage 
> > collector"
> > in their process. Either distributed among team members or 
> one person 
> > responsible for cleaning up. No nice job... but it needs to be done.
> > 
> >      Marcus
> 
> Sidenote: There are a multitude of cool things piling up on 
> SM that we need to consider if we want to "bless" as being 
> part of the official package pool. A good example is Shout - 
> it is so DAMN good it should be an official package IMHO. :) 
> And it should be in Basic.
> 
> Now, what we can do is to simply agree on this - the 
> maintainer must be in on it of course - and then Doug can 
> simply put out an update loading it. Voila.
> 
> Now, of course - 3.7 is close at hand so I propose we take a 
> look at these things in the beginning of 3.8. Removals and additions.
> 
> regards, Göran
> 
> 
>