On 23/02/05 08:11, "Cees de Groot" <cg at cdegroot.com> wrote:

> Hi All,
> 
> After the deafening silence on our plans, I take it you all agree with it
> but are just to shy to speak up in public ;)
> 
> Anyway, here's a team proposal. I'm Team Leader Ad Interim - if someone
> else wants the job, there's a good chance I'll step down because I'll be
> busy enough as it is.
> 
> Goal: split up Morphic into 'Mini Morphic' and 'Rest Of Morphic'
> 
> Timeline: June/July
> 
> Acknowledgements: Avi and Dan, I think.
> 
> Details:
> 
> Morphic has grown a bit big and ugly. This has had various reasons, all
> probably very good design decisions at the time they were made, but it's
> about time to clean up this legacy.
> 
> A very big part of Morphic is 'just' there to support eToys (let me stress
> that we squeak-dev'ers are a minority user group!). We're lugging it with
> us, trying to keep it in shape, but we hardly use it. Also, because
> Morphic+eToys has grown such a big thing it is nigh impossible to clean it
> up. So, the immediate plan is to untangle this Gordian Knot - we have one
> handicap that Alexander didn't have: swords are not allowed ;)
> 
> The MINIMAL deliverable of this project is:
> - CoreMorphic package. World/project support + the UI bits for ToolBuilder
> to operate.
> - FatMorphic package. All the rest of it.
> - eToys package.
> These packages should all be loadable/unloadable on demand. We'd like
> Squeak to become UI-neutral, so it must become simple to swap Morphic for
> MVC or vice versa (or for Tweak, wxSqueak, ...).
> 
> CONDITIONS:
> - The community accepts that if this team is instated AND delivers at
> least the minimal deliverables, these deliverables will become part of the
> next release of Squeak after delivery.
> 
> OPTIONAL deliverables:
> - While we're at it, make MVC a loadable/unloadable package;
> - Refactoring. Cutting out dead wood from especially FatMorphic that's not
> needed;
> - Further splitups of FatMorphic, if it turns out to be logical.
> 
> DEPENDENCIES:
> - We use ToolBuilder to define what CoreMorphic is. I.e., whatever
> ToolBuilder needs, lands in CoreMorphic. Whatever ToolBuilder does not
> need, does not land into CoreMorphic. The project assumes that ToolBuilder
> will be in the image that will be used to release the Team's deliverables.
> 
> NON-DEPENDENCIES:
> - We are not going to assume that any output from any package/modules team
> is ready in time. So straight PackageInfo is our basis.
> 
> I repeat that a conditio sine qua non for this project is that eToys
> becomes loadable/unloadable and keeps working. So it's not a matter, as
> the 'strippers' do, of just cutting off the excess fat; it needs to be
> carefully trimmed of and kept apart. Which makes it a job not much more
> glorious than Ken's 'Janitors' Team ;). After we've delivered, the idea is
> to have people sign up for maintenance of these various packages, where my
> expectation is that the Squeaklanders will start taking care of the eToys
> package.
> 
> Joining:
> 
> Announce here on the list or through private mail to me. When no
> objections from the community arise and there are enough people that join
> up, I'll ask my colleague coordinators to declare it as a Team and setup
> list+swiki+MC storage. If you want to become the Team leader for this,
> please drop me a mail with motivation etcetera.
> 
> Regards,
> 
> Cees
> 
> 
> 
Count me too!

Edgar