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.html 
  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