release team proposal

Ralph Johnson johnson at
Fri Nov 24 14:53:55 UTC 2006

On 11/23/06, Klaus D. Witzel <klaus.witzel at> wrote:
> I appreciate your initiative and would like to know more about what you
> consider to be a core package and, what is the resulting image when you
> subtract all the core packages. Do I have to understand this being based
> on a kernel image and, what about Pavel's kernel image?

Are you asking "what are we going to subtract"?  I do not know.  I
would like to see anything subtracted that can then be added back in.
Lots of people are interested in splitting eToys into a separate
package.  I don't think anybody will argue with this as long as it can
be loaded back in.  However, I do not think of that as necessarily
being a release team responsibility.  Pavel Krivanek is working on
eToys and seems to be doing a good job.  In general, we are going to
focus on the process of transforming the image in such a way that
other programs are affected as little as possible.  We'll emphasize
supporting other people making transformations and not plan to do it
all ourselves.

If I made a list of things that should be separate packages, it would
look a lot like other people's lists.  I want the release team to
focus on the *process* of splitting the image into packages, not the
particular set of packages.  You can't have a good process unless you
practice it constantly, so we will make packages as well as helping
other people make packages.  My guess is that other people will do the
high-impact, high visibility packages, and I will do the boring ones.
Edgar is working with Pavel on eToys and Morphic, but that is too big
a project for me right now.

> > Each bug fix would have a test that shows the bug
> > and that shows that it is fixed.
> What about non-bugs, like for example performance issues. Or do you count
> them to the bug category.

New changes shouldn't break any of the existing tests.  I suppose that some
of them will come with their own tests, and some won't.  It would be good for
Squeak to have more tests, but we are not going to be hard on people about


More information about the Squeak-dev mailing list