Igor Stasenko wrote:
> Andreas, i read about your concerns about MC and i feel like MC
> currently is abandonware,
> since its not maintained by anyone, yet it is de-facto standard tool
> for sharing the code in squeak universe.
> This situation is really bad and we need to change it.

So what are you proposing to change it?

Cheers,
   - Andreas

> Also, i am strongly thinking that MC should be maintained as separate
> entity, because it is crucial for developers to
> have a tools which can be used to share the code among forks and
> therefore this tool should behave equally everywhere.
> 
> On 2 February 2010 08:25, Andreas Raab <andreas.raab at gmx.de> wrote:
>> 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
>>
>>
>>
> 
> 
>