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.