[squeak-dev] MC 1.5/1.6 (Re: [Cuis] Cuis - Cross fork compatibility of packages: A proposal)

Igor Stasenko siguctua at gmail.com
Tue Feb 2 07:56:12 UTC 2010


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.

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



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list