release team proposal
karl.ramberg at chello.se
Fri Nov 24 17:03:40 UTC 2006
Ralph Johnson skrev:
> On 11/23/06, Klaus D. Witzel <klaus.witzel at cobss.com> 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
>> them to the bug category.
> New changes shouldn't break any of the existing tests. I suppose that
> 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
I have a question about tools. There are some issues with Monticello and
refactoring where methods moved between packages disappears. Another
issue is load ordering, Monticello does not do atomic loading. A third
is dependencies between packages. These issues caused a lot of headache
for the 3.9 guys. How should we approach these issues ?
More information about the Squeak-dev