[V3dot10] my plans for alpha and beyond

[Ralph Johnson]

My plans for the alpha release is to use the image that Edgar has
made.  So, you really ought to take a look at it and let us know if
you have any objections.  The image is basically 3.9 with some
packages removed.  In addition, I will make the testing policy that
all submitted changes should pass all the existing tests, i.e. "tests
should be green".

I was hoping to have a testing server for the alpha release, but I
just found out that the student working on it has not progressed very
far.  So, we'll have to do that later.  But at least we can start with
a simple testing policy.

My goal is to drastically componentize Squeak.  I've looked over
Pavel's KernelImage, which makes Morphic a loadable component, and
like it a lot.  This is the future of 3.10.  My goal is to set up a
process so that we can accept a change as big as this.  It is a very
big change!  But the advantage of componentizing Squeak like this is
that it makes it much easier for people to make alternative UIs, to
make minimal images without Morphic, and so on.  To be successful, we
have to be able to pull all the pieces together to make an image
compatible with what we have now.  The process has to make this not
only possible, but easy.  That is hard!

Suppose we split Squeak into components.  It is not enough to test a
change to a single component.  You have to test changes in one
component against all the other components.  Right now, people want to
put their changes in the image because they know that if their code is
"second class" then people will change the image and break their code.
 If they can put their code in the image then there is more of a
chance that people will change the image in ways that keeps their code
working.  If we want to split Squeak into components, we have to
change this way of doing things.  We have to have the rule that
changes to Squeak must not only keep all the tests in the image green,
they have to keep all the tests in the components green.  We could do
this testing by hand if there are only two or three components, but
there will be hundreds of them, and so we will have to have a test
server to check that all the tests are green.

So, the release team will be responsible for the image and for a set
of official components.  We need a name for these components;
"supported", "official", "approved", "core".  None of these names are
perfect.  I'd like to find a perfect name for them.  The test server
will have to test combinations of components.  It doesn't need to test
an exponential number of combinations.  For starters, it could test
each component individually and then test all of them together.
Except that sometime two components will not be compatible with each
other (they are alternative implementations of Date, for example) and
so a little exponential growth will occur.  We can handle it if there
are only two or three cases, but not if there are a hundred.

i have not said what a "component" is or what a "change" is.  I'll
deal with that in my next message.

-Ralph