[squeak-dev] MC 1.5/1.6 (Re: [Cuis] Cuis - Cross fork compatibility
of packages: A proposal)
andreas.raab at gmx.de
Tue Feb 2 06:25:55 UTC 2010
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
a) Fix the issues that have been reported so far
b) Run the experiment described in
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
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.
More information about the Squeak-dev