How to improve Squeak

Ned Konz ned at squeakland.org
Mon Jul 12 00:43:02 UTC 2004


On Sunday 11 July 2004 2:36 pm, goran.krampe at bluefish.se wrote:
> "Tighter" would "kill" the joy and joy is what we thrive on. In fact -
> as I said - we need a swifter process with more trust in the experienced
> developers. The harvesting process is perfectly fine for handling ENHs
> and FIXes coming in from less experienced developers - but it should
> IMHO not be used for core development by the more active experienced
> Squeakers.
>
> We need something similar to a CVS with an update/commit process based
> on trusted core developers. And I think we may try to put something like
> that in place pretty soon - there have been a few experiments. And even
> if we don't put that in place for the image - it is used or can be used
> for the packages being broken out of the image.
>

I absolutely agree with this. I think we should make it easier for our more 
experienced and trusted developers to get fixes into the system.

I think there should be something equivalent to the old Squeak Central 
"internal update stream", but with more public visibility.

We have been so conservative with reviewing individual items because there are 
a number of people (too many, probably) using the pre-release versions of 
Squeak for everyday work. As a result, we don't want to break too much.

This results in a slow-moving process, with the same added overhead being 
applied to every little fix.

Instead we should have a fast-moving, probably often broken but quickly fixed 
development head (like most other open source development efforts) with 
commits available to the core developers.

That head should then get forked to become the release versions, as is also 
typical. These should go through more rigorous testing, and should be usable 
by beta time for most people.

Using a bug tracking system (no, we don't have to write our own!) would give 
better tracking, threading, assignment of responsibility, etc.

A simple tool in Squeak for submissions (as we have now), or a harvester on 
the existing lists would be adequate for getting external submissions.

-- 
Ned Konz
http://bike-nomad.com/squeak/



More information about the Squeak-dev mailing list