How to improve Squeak

Doug Way dway at mailcan.com
Sun Jul 11 19:34:40 UTC 2004


On Jul 11, 2004, at 2:47 PM, Brad Fuller wrote:

> Hi all,
>
> What is the criteria and approval process of being in the base image?

The approval process (Harvesting Process) is pretty much covered here:

http://minnow.cc.gatech.edu/squeak/3152

Note that there aren't really strictly defined criteria for something 
to be allowed in the base image, other than approval/review from one or 
more harvesters and other volunteers.  However, most of the things 
being discussed here (Squeak Server Pages, EventRecorderMorph, etc) 
pre-date the existence of the Harvesting Process anyway. (they were 
added earlier in the days of Squeak Central)

- Doug


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




More information about the Squeak-dev mailing list