Hi Ken -
Ken G. Brown wrote:
I am finding it somewhat odd that you seem to be willing to hack your ancient trunk fork of MC any which way, but with the big potential wins of the MC1.5/1.6 versions, I'm thinking someone like yourself with the necessary detailed system knowledge, might be able to apply some appropriate fixes to bring MC into a better working state. Even if it might be an interim solution, it seems to me there could be some real gains.
I think you're misunderstanding my relationship with MC. I don't particularly like MC, I find the code base very hard to understand and very difficult to follow due to the complete lack of any comments. Self-documenting code my a** as one of my colleagues here would say.
The amount of MC that I have mastered is *just* the package loader and only because I had to in order to fix various broken operations. In the process of mastering it I've added comments to explain what I think happens but from some of the discussion it is obvious that I'm still missing various subtleties.
Looking at MC 1.5 I found nothing but more undocumented changes. The practical problem I've encountered makes no sense whatsoever to me (removing a changed method prior to compiling the new version cannot possibly work) but it's actually *different* from the prior version and there is no context to judge *why* it's different.
So if you're asking me why I'm not fixing Monticello one part of the answer is: I don't like MC, and unless I absolutely have to I'll stay away from it.
However, just as importantly, when we change a critical piece of the infrastructure I'm also looking for who will be providing support for any issues that come up. If something goes wrong in one of these areas, we need help and that help needs to come from the people who wrote that code. A great example in this regard were the recent changes to both CompiledMethodTrailer (Igor) and the >32MB changes file (David).
Both of these had issues come up that could have been the result of the changes they did. In both cases, Igor and David were *happy* to help and to dig into the details to make sure people get over these significant changes in the system. They didn't ask the users to fix the problem, they said "thanks for reporting the issue, could you try this or that, and here's the fix".
That's the reaction I'm looking for when someone wants to push changes to the core system. I'm *not* looking for them telling their testers to go fix it yourself (neither am I looking fpr people dumping their unfinished projects into my lap). That's the wrong attitude.
So if you want to get a newer version of MC into the trunk, the process is this: a) Fix the issues that have been reported so far b) Run the experiment described in http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-October/140345.h... to ensure you can load everything in the trunk c) Report your success here
At the point where you've successfully re-run the updates in the trunk to ensure that your version of MC can deal with everything currently in use we're in a situation where a switch to MC 1.5 / 1.6 is a win-win situation.
Obviously, you don't have to do this all by yourself; if you can find help from people that works just as well. And if you add a few comments explaining what precisely the loader does and why that order and these operations are necessary, I might even give it a second look myself.
Cheers, - Andreas