release team proposal

karl 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 
>> 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
> this.
>
> -Ralph
>
>
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 ?

Karl



More information about the Squeak-dev mailing list