For the way ahead I still think we are limited by our tools, which is 
what I thought when 3.10 started.

The improved testing philosophy that has been part of the 3.10 release 
has been a start, but squeak is a multi-platform, multi-configuration 
testing problem, and so I feel that more tool support for this is needed.

To work towards solving this:

1. Launcher - provides the ability to launch, configure, install 
packages and test different images from the command line.
2. Installer - provides the ability to install packages/fixes from 
whatever sources
3. SUnit-improved - provides
    a. the ability to mark tests as specific to vm or image release, or 
platform (e.g. mark a test for 3.10 or greater) so that test suites can 
be more generic.
    b. filtering based upon the above (e.g. exclude tests that are not 
expected to work in this vm/image version or platform etc)
    c. the ability to time tests and categorize them so that all of the 
fastest tests can be run first to get greater coverage sooner.
    d. Non-GUI test runner, which generates output to files, for testing 
older/smaller/gui-less squeak configurations.

I think that the missing part in all of this is the bit that defines 
what exactly is to be built and tested. I have called this part Bob (the 
Builder). I wrote a version of Bob in 'ruby' which uses a public wiki so 
that the community can define the "What". I think that the next version 
of Bob will use a/some Monticello packages to define the "what", in this 
way the "what's" are subject to source control etc.

The above represents just the tools for building and testing. As for 
actually working on the next version, the bottleneck for working on the 
image has been the package loading/ management tools. i.e. Monticello 
and changesets etc.

I still believe in managing the kernel image in packages. Although 
changesets have their place for incremental changes, I still think that 
at the end of the day a subsystem should be 'deliverable' as a package.

The problem with this approach so far is that the tools just have not 
been up to it and have caused major headaches for recent release teams. 
I think that future releases will struggle to be more than minor 
incremental bug fixes until this is actually solved. The new 
DeltaStreams initiative is a second vote for better tools to address 
this area.

Monticello 1.5 is much better at managing Packages with overrides and 
extensions than 1.0.This provides the basis for actually teasing things 
apart into clearer packages. But we have a couple of bugs to find, and 
when we have SystemEditor working for true atomic loading we should 
finally have the basis for managing the image in packages.

Once the tools are in place we will be able to spec out a road map (or 
two) using "Bob" containing

a. bug fix collation
b. modularization and removal of bits
c. new features etc

Then volunteers can work on their bits and Bob can perform the 
integration test cycles.

This approach differs from the DeltaStreams idea where anyone can 
publish or subscribe to many delta streams. The idea here is to be able 
to plan a new release up front, to divide up the work required to 
acheive it and to formally integrate the parts back into a coherent 
tested whole (+ packages).

my 2p

Keith