> 
> Well I would be _very_ happy if you would take one being "chief in charge of
> refactoring the image".

Just that ;)
I'm willing to help sure. My problems is that I read the wiki and still do
not understand well what is module for you and all the implications of your
design. 
>From what I read I can say that you provide much more that Ginsu at the
language semantics level. This is fun that you say that this is minimal
because there is really nothing in Ginsu. But once you will realize it.
You propose more than a packaging organization. This is not a problem.

I have problem to see if keeping changes sets is really the way to go and
how deltaModules are related to class extensions and modules them.
I will discuss with Andrew to see if we can come up with a common
understanding.




> In fact, I think there is a vacancy for this
> position that really needs to be filled! In any case, I would be grateful
> for comments on my architecture proposal at
> http://minnow.cc.gatech.edu/squeak/2057

I think that you should discuss with joseph and john if they attend OOPSLA.
Because joseph has a lot of experience in this area. Much more than me. ;)



****The key point of the email is here ******
Have you something like in Ginsu that sorts the classes into modules
according to a spec? And put apart the methods that violates the visibility?
Because like that you can design you modularization and check if this is ok
then identify the problems.
I think that this is most important point because I think that we should
have Squeak3.1 then that people can continue to collect changes, propose bug
fixes and in the meantime that we can come up with a cleaner system.

Having tools will help us to reintegrate the changes proposed for Sq3.1 and
also the future changes in the future (Sq3.2).





Like in ModSqueak I would use chainsaw design: remove everything big part
like Etoy, speech, Alice,....that can be removed first. Then look at the
Kernel. Then do a major shrink plus a complete recompilation of the methods
and classes is necessary. Fixing the problems there would help to have a
clean kernel. 
the new filelist and SessionManager would definitively help there. I think
that you will see that lot of methods are broken. We may ask Jon Sarkela
because he found a lot of strange code in the release methods.

All the kernel removed method should be tagged as deprecated.
It would be good if we could develop some unit tests per kernel modules. But
we should not dream too much.


Ideally I would have been great to get this work sponsored by the squeak
foundation. Put in the room a bunch of excellent guys and wait one or two
weeks...;) because this would be the best way to do it.

For the modularisation I think that we should take care about the
propagation of versions among dependent modules. The idea is that if AV1.1
depends on BV2.3, BV2.3 on C9.0
Then everytimes you change C to a newer version you will have to change all
the other versions. So the idea is that the kernel should be more stable and
having a different change frequency than the its dependent.

> Hopefully, but the general rule seems to be that the people who are willing
> to contribute to something are much fewer than those who want to have it.
> 
>> But the problem is not doing it: the point is having it into the image and
>> controlling the changes that's why these modules are so important. We will
>> be able to work on a part of Squeak and controlling its changes.
>> 
>> What is important after the modules are started is to say to all the brave
>> souls around: "ok if you want to be responsible for something please be and
>> we can organise a kind of peer reviews"
> 
> In general I agree. But this won't work before the system has been untagled.
> Since the system is tangled now, I'm afraid you cannot fix one area, say the
> compiler or Morphic, without also touching other parts of the system. Like
> you wrote, untangling Morphic also means changing the compiler, etc etc. So
> this will be a messy process indeed.

That's why we should identify priorities and for example simply remove bad
code and tangle thing unnecessarily. I was thinking about this GifReader
References and other.

> 
> I meant that the code of Ginsu itself most likely changes a lot of the same
> methods that this code does.

I do not see it. Ginsu does not change code. it organizes it and they built
a thin layer that represents declarative code. That's it. No changes for
method lookup or whatever. There is no scoping mechanism at the language
level. Ginsu is just sorting classes inta bags that can see each other if
necessary. But when something is loaded in memory there is no namespace.
Ginsu is about packaging code and make sure that onece all the dependent
module are loaded your code will work. No more.