[V3dot10] my plans for alpha and beyond

[Milan Zimmermann]

Ralph,

I was waiting not to be first to comment but cannot wait much longer :) . For 
what it's worth from someone who does not have experience buidling large 
systems in Smalltalk, I like this very much. Defining boundaries of 
packages/components, separating them, and auto-testing whether they still 
work together is not only pleasing, but also should enable thinks like well 
defined per-component ownership by individuals and groups, pluggability and 
probably better reliability. There will be probably large difficulties as you 
also described. I will have more notes later , and realize you said you will 
describe what you mean by a "component" later, at this point I wonder about 
how the component boundaries will be defined, and whether somehow exporting 
(I really mean defining/fixing) their API will be part of the  process. There 
probably could be some iteration to the process - A concrete example of what 
I mean is , Morphic and eToys could perhaps be dealt with as one "component" 
initially, loadable together, and later separated them into 2. I should 
really look at how Pavel separated Morphic and what is in that piece.

In any case this sounds like a great plan, Milan

On 2007 January 18 07:14, Ralph Johnson wrote:
> 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
> _______________________________________________
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/v3dot10