[V3dot10] my plans for alpha and beyond
milan.zimmermann at sympatico.ca
Fri Jan 19 08:11:58 UTC 2007
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.
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
More information about the V3dot10