RV: [V3dot10] my plans for alpha and beyond

> De: Ralph Johnson <[hidden email]>
> Responder a: "Discussion about development of Squeak 3.10"
> <[hidden email]>
> Fecha: Thu, 18 Jan 2007 06:14:59 -0600
> Para: "Discussion about development of Squeak 3.10"
> <[hidden email]>
> Asunto: [V3dot10] my plans for alpha and beyond
>
> 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
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/v3dot10