2009/11/6 Ken G. Brown <kbrown at mac.com>:
> IMHO, such smart guys that are doing the majority of contributions to trunk could have figured out the way forward with Keith's established future methodology using Installer, Sake/Packages, Bob the Builder, MC 1.5/1.6 in about ten minutes.  Some were already up to speed on the way forward. They could then have contributed fixes to the tools for that methodology where required and we would be now in the future instead of stuck in the past, forked yet again with the old trunk methodology (it's not a 'new' development model) that got us into the difficulties in the first place.
>

Ken, as i said before, i would be really happy to have MC 1.6 adopted
by trunk and pharo.
And given the feedback of other people, they want it too.
I think that MC should be a standalone project, which can be loaded to
virtually any squeak fork.
But we need people who actively maintaining it and improving it.
And definitely, MC should be not a core part of system. It should be
made optional, as any other non-kernel part of system.

Once this will happen, we could move forward and adopt next tools &
methodology. Step by step.

So, Ken, if you think you are motivated enough, step forward and make
an offer to community.
And we can discuss the plan & organization of MC maintenance. Because
its really bad that such critical part of system,
which used by multiple forks, don't have any central comitte, which
watching the progress, pushing the fixes and moving it forward.

> Ken G. Brown
>
>
> At 2:23 PM -0300 11/6/09, Jecel Assumpcao Jr apparently wrote:
>>Ronald Spengler wrote:
>>> When the announcement that there was going to be a trunk repository
>>> and a contrib repository was made, I suddenly had hope again. The fact
>>> that there was a two-man release team that I didn't even know about
>>> (being a noob, I guess) didn't make a whit of difference to me,
>>> because they weren't shipping anything.
>>
>>There was actually a one man release team (Matthew for 4.0) and another
>>two man release team (Keith and Matthew for 3.11), and though they both
>>were very busy with other things in their lives I think the board's
>>position (which I fully agreed with) that the relicensing was the
>>priority and new development would complicate it was the main cause of
>>the seeming lack of progress in Squeak. And I actually looked at the
>>archives of the Pharo mailing list at the time and compared it with the
>>number of entries on Mantis and found out that though they seemed very
>>different, the level of activity in both projects was comparable.
>>
>>Unfortunately, appearance can matter more than reality. The *right*
>>thing for the board to have done would be to talk to Matthew and Keith
>>about the new direction, have a final vote in the following meeting and
>>then announce it here. Letting Keith find out with everybody else was
>>bad, so I see where the scheme explained by Phil would come in. But my
>>impression at the time was that two weeks of silence on squeak-dev (to
>>wait for the next board meeting) would cause lots of people to leave and
>>they might not later hear about the new process and decide to come back.
>>So I voted we do the wrong thing instead (the needs of the many outweigh
>>the needs of the few and that sort of thing) and still stand by that
>>decision.
>>
>>I can't imagine some higher authority defending a developer from the
>>board even if this episode shows the need for something like that. So
>>the alternative is to complain about anything you don't like here on
>>squeak-dev. That has been done and even though there seemed to be no
>>immediate results it might have an effect (or not) in the next election.
>>
>>-- Jecel
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.